Hey there,
I just ran through a theory, and it seems it's possible to also register a 'sharepoint add-in' by actually configuring an app reg (which creates an enterprise app) first in the Azure Portal, and then skipping the registeration process found in these docs and simply inviting the app, and granting it perms. I wonder if it might be beneficial to share those steps in this doc too.
I ask because, if you're a site collection admin, it seems to let you do the appregnew.aspx page, and that creates a SP/Enterprise app in your tenant. It also generates a secret at that time. However, that client secret can't be managed by the site collection admin(s) of the site, unless they are also tenant admins. This of course, can be cumbersome as by default, that client secret expires after 1 year, and there's not a great way for someone to manage it. There are definitely use cases out there where the people dealing with the site/app should be the maintainers of the app, not the tenant admins.
Creating apps/add-ins this way seem to be a decent way to get an app access to a single sharepoint site, but I think it's even better if it's done via the app reg blade on portal. This way, the person(s) who create the site can fully mange the client secret(s) via the app registration blade, and are able to update it themselves without tenant admin involvement.
I basically ran through this using an app registration instead, and it seems to work the same way, but instead, the client secret is stored w/ the app registration and is completely manageable by the owner(s) of the app.
If there's not anything I'm missing, I'd love to see the docs updated to add (and maybe even suggest) this method, and update corresponding docs that talk about maintaining the secrets (namely: https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins/replace-an-expiring-client-secret-in-a-sharepoint-add-in) to also include this use case.
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.
Hey there,
I just ran through a theory, and it seems it's possible to also register a 'sharepoint add-in' by actually configuring an app reg (which creates an enterprise app) first in the Azure Portal, and then skipping the registeration process found in these docs and simply inviting the app, and granting it perms. I wonder if it might be beneficial to share those steps in this doc too.
I ask because, if you're a site collection admin, it seems to let you do the appregnew.aspx page, and that creates a SP/Enterprise app in your tenant. It also generates a secret at that time. However, that client secret can't be managed by the site collection admin(s) of the site, unless they are also tenant admins. This of course, can be cumbersome as by default, that client secret expires after 1 year, and there's not a great way for someone to manage it. There are definitely use cases out there where the people dealing with the site/app should be the maintainers of the app, not the tenant admins.
Creating apps/add-ins this way seem to be a decent way to get an app access to a single sharepoint site, but I think it's even better if it's done via the app reg blade on portal. This way, the person(s) who create the site can fully mange the client secret(s) via the app registration blade, and are able to update it themselves without tenant admin involvement.
I basically ran through this using an app registration instead, and it seems to work the same way, but instead, the client secret is stored w/ the app registration and is completely manageable by the owner(s) of the app.
If there's not anything I'm missing, I'd love to see the docs updated to add (and maybe even suggest) this method, and update corresponding docs that talk about maintaining the secrets (namely: https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins/replace-an-expiring-client-secret-in-a-sharepoint-add-in) to also include this use case.
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.