Dynamically Granting Application Permissions for Teams Store Apps

Question

Dynamically Granting Application Permissions for Teams Store Apps

Neelu George 40

I am publishing a multi-tenant app to the Teams Store. The app has core features requiring basic permissions and 'Advanced Features' that require additional Application Permissions.

I want to avoid requesting high-privilege permissions upfront. Instead, I want to programmatically grant these extra permissions via the Microsoft Graph API (using an admin’s delegated token) only when a user opts into the advanced features.

I could successfully do this with sideloaded apps, but is this workflow supported for apps published through the Teams Store? Specifically, can I grant Application Permissions that were not pre-defined in the app's manifest at the time of publication?

Appreciate any help!

AnandJoshi-MSFT 0 Reputation points Microsoft Employee

2026-04-30T06:32:02.2633333+00:00

@Neelu George , how did you manage to do it for the sideloaded experience? If you can share what that end-user flow looks like for you right now, I can comment if the same is feasible or not for an app published to the Teams Store.
Neelu George 40 Reputation points

2026-04-30T09:38:29.35+00:00

Hi @AnandJoshi-MSFT

In the sideloaded approach,my App registration in my home tenant has only basic App Permissions added.

But I take "AppRoleAssignment.ReadWrite.All" as a delegated permission from the admin at the time of advanced feature request.This allows me to add Application Permissions that are not listed in the uploaded manifest(and not in actual App Registration in home tenant), using GraphAPI.

Reference:
Grant an appRoleAssignment for a service principal

2 answers

Your answer

AnandJoshi-MSFT 0 Reputation points Microsoft Employee

2026-04-30T06:32:02.2633333+00:00

@Neelu George , how did you manage to do it for the sideloaded experience? If you can share what that end-user flow looks like for you right now, I can comment if the same is feasible or not for an app published to the Teams Store.
Neelu George 40 Reputation points

2026-04-30T09:38:29.35+00:00

Hi @AnandJoshi-MSFT

In the sideloaded approach,my App registration in my home tenant has only basic App Permissions added.

But I take "AppRoleAssignment.ReadWrite.All" as a delegated permission from the admin at the time of advanced feature request.This allows me to add Application Permissions that are not listed in the uploaded manifest(and not in actual App Registration in home tenant), using GraphAPI.

Reference:
Grant an appRoleAssignment for a service principal

Answer 1

Hin-V 14,180 Microsoft External Staff Moderator

Hi @Neelu George

Good day, and thank you for sharing your question.

Based on my research, looks like this workflow is not supported for apps published through the Microsoft Teams Store.

Application permissions in Microsoft Entra ID / Microsoft Graph do not support dynamic or truly incremental consent. Unlike delegated permissions, application permissions must be pre‑defined in the app registration (requiredResourceAccess) and cannot be added or granted programmatically at runtime, even when using an admin’s delegated token.

References:

Developer’s Guide to Requesting Permissions and Consent in Microsoft Identity Platform - Microsoft …

Your approach works with sideloaded or tenant‑specific custom apps because you retain full control over the app registration within the tenant. However, once an app is published to the Teams Store, the permissions declared in both the Teams app manifest and the Microsoft Entra ID app registration are subject to security and compliance review and are effectively fixed at submission time.

As a result, you cannot grant application permissions that were not already declared when the app was submitted to the Teams Store.

I hope this helps.

If you have any additional concerns, feel free to comment below. I would be more than happy to assist.

Note: Please follow the steps in [our documentation] to enable e-mail notifications if you want to receive the related email notification for this thread.

Neelu George 40 Reputation points

2026-04-30T05:06:47.51+00:00

Hi @Hin-V

Thank you for your detailed response.

In the sideloaded approach, I haven't specified the extra permissions in the app manifest which I upload.

But I take "AppRoleAssignment.ReadWrite.All" as a delegated permission from the admin at the time of advanced feature request.This allows me to grant Application Permissions that are not listed in the uploaded manifest(and not in actual App Registration in home tenant), using GraphAPI.

Does this mean app manifest comparison is not done in Sideloaded flow, but would be enforced for Teams Store Apps?

Also can you guide me on how this incremental Application Permission assignment is done usually.
My application needs something like Chat.Read.All, ChannelMessage.read.All only in case of this advanced feature
Hin-V 14,180 Reputation points Microsoft External Staff Moderator

2026-05-02T22:46:00.3733333+00:00

Hi @Neelu George

Thank you for your responding.

Yes, your understanding is correct. In the sideloaded flow (or any single-tenant app you fully control inside one tenant), Microsoft does not perform any manifest comparison or strict enforcement. You only request the delegated permission AppRoleAssignment.ReadWrite.All from the admin, then use the admin’s delegated token plus Microsoft Graph to create appRoleAssignments for any Application Permission you want, such as Chat.Read.All or ChannelMessage.Read.All. This works because AppRoleAssignment.ReadWrite.All is powerful and sideloaded apps have no Store certification process to lock down the manifest.

For apps published to the Teams Store, this approach might not work. When you submit a multi-tenant app, Microsoft reviews both the Teams app manifest and the Entra app registration. The declared permissions become fixed at publication time for security and compliance reasons. You cannot grant any Application Permissions that were not already declared when the app was submitted, even with an admin token that has AppRoleAssignment.ReadWrite.All. The Store policy and runtime behavior will block or ignore undeclared high-privilege permissions.

The incremental Application Permission assignment you described in the sideloaded approach is typically performed using the Microsoft Graph API after requesting the delegated permission AppRoleAssignment.ReadWrite.All from the admin. You obtain an admin delegated access token that includes this permission, then make a POST request to the endpoint /servicePrincipals/{resourceServicePrincipalId}/appRoleAssignedTo (where resourceServicePrincipalId is the object ID of the service principal exposing the roles, such as the Microsoft Graph service principal for Chat.Read.All or ChannelMessage.Read.All). In the JSON body you specify your app’s service principal ID as principalId, the same resourceServicePrincipalId again as resourceId, and the exact appRoleId of the permission you want to grant (you can look up these role IDs by querying the appRoles collection on the target service principal first). This creates the appRoleAssignment on the fly, granting the permission at runtime even if it was never declared in your Teams manifest or Entra app registration.

This works for sideloaded or single-tenant apps because there is no manifest validation or Store review process. However, for apps published to the Teams Store this exact dynamic method is not supported or reliable, which is why you should declare everything upfront.

If you need further assistance, feel free to reach out.

Warm thanks.
Neelu George 40 Reputation points

2026-05-04T13:30:16.8666667+00:00

Thanks @Hin-V for the detailed explanation!!!
Hin-V 14,180 Reputation points Microsoft External Staff Moderator

2026-05-05T18:17:15.23+00:00

Hi @Neelu George

Thank you for your response and feedback.

If you found my reply partially helpful, you’re welcome to upvote it or mark it as the accepted answer. This helps others in the community who may encounter similar issues and contributes to the growth of our forum by strengthening our shared knowledge base.

If you need any further assistance on this topic, please don’t hesitate to reach out. I’d be more than happy to help.

Warm regards.

Answer 2

For a Teams Store app, application permissions must be predefined and consented to; dynamically adding new application permissions at runtime for a published store app is not supported.

Key points based on the documented models:

Permissions must be declared up front
Microsoft Graph permissions for an app are defined on the Microsoft Entra app registration (static permissions) or requested via dynamic consent at runtime. Dynamic consent is explicitly described as working with delegated permissions:
- Dynamic consent "can be used with delegated permissions" and combined with /.default to request admin consent for all permissions already configured on the app.
- Application permissions are not requested via the same dynamic consent flow; they require admin consent on the app registration/service principal.
Store apps and least privilege
For Teams apps intended for distribution, guidance is to design around the principle of least privilege and to request only the minimum permissions needed to function. This is specifically called out for Teams apps using Microsoft Graph:
- Apps should request the fewest, least-privileged permissions to improve adoption and admin approval.
- Resource-specific consent (RSC) and delegated permissions are preferred where possible; application permissions carry the highest privacy risk.
Granting/revoking permissions programmatically
Microsoft Graph supports programmatic grant/revoke of permissions (both delegated and application) by manipulating the underlying objects (for example, app role assignments for application permissions). However:
- This mechanism is an alternative to interactive admin consent, mainly for automation/bulk management.
- It still operates only on permissions that exist on the app registration. It does not bypass the requirement that the permission be part of the app’s configured access to the resource.
Implication for a Teams Store app
For a multi-tenant Teams Store app:
- Application permissions that might ever be granted must be configured on the app registration before publication (and thus effectively “known” at publication time).
- An admin can choose when to grant those application permissions (interactively or programmatically), but cannot grant application permissions that were never configured on the app registration.
- Dynamic consent at feature opt-in time can be used only for delegated permissions, not for introducing entirely new application permissions that were not preconfigured.

Therefore, the workflow where a published Teams Store app later gains new application permissions that were not pre-defined in the app registration/manifest is not supported. The supported pattern is:

Preconfigure all potential application permissions on the app registration (and reflect them appropriately in the app’s documentation/manifest expectations), and
Use admin consent (interactive or programmatic) to grant those permissions when a tenant admin chooses to enable the advanced features.

New, previously undefined application permissions would require updating the app registration and republishing/redistributing the app rather than being added dynamically at runtime.

References:

Share via

Dynamically Granting Application Permissions for Teams Store Apps

2 answers

Your answer