Microsoft Graph API permission

Question

Hello,

I'm currently working as an intern and I'm building an application using the Microsoft Graph API. My app needs access to a single mailbox and to the SharePoint sites linked to one specific Teams team (including its private channels).

I found the following official documentation to restrict these accesses:

• Restrict mailbox access: https://learn.microsoft.com/en-us/graph/auth-limit-mailbox-access
• Resource-Specific Consent (RSC) for Teams: https://learn.microsoft.com/en-us/microsoftteams/platform/graph-api/rsc/resource-specific-consent

However, our organization doesn't have a dedicated IT/tech team to handle the Exchange Online PowerShell configuration (for the Application Access Policy) or the Azure admin-level settings required for RSC.

Is there a graphical alternative in the Azure Portal or the Microsoft 365 Admin Center to achieve the same result without using PowerShell? Or is there another approach that would allow me to restrict the app's permissions to a single mailbox and a single Teams team without requiring admin-level PowerShell commands?

Thank you in advance for your help.

Answer 1

Hello MagiCapSss

Thank you for reaching out to Microsoft Q&A.

Thanks for the details—unfortunately, there’s no full GUI path today in the Azure Portal or Microsoft 365 Admin Center to:

• Create an Exchange Application Access Policy (that still requires Exchange Online PowerShell or Graph calls)

• Turn on and scope Teams Resource-Specific Consent (you still need PowerShell or Graph to register the app for RSC and assign it to a team)

If you want to avoid any admin-level PowerShell you can switch to delegated/user-consent flows and use built-in portal blades to scope who can sign in. Here’s how:

1. Use delegated mailbox access instead of app-only • In Azure AD Portal ➔ App registrations ➔ Your app ➔ API permissions, add a delegated Mail.* scope (e.g. Mail.Read.Shared) • Grant admin consent once (or enable user consent if your tenant allows it) • In Azure AD ➔ Enterprise applications ➔ Your service principal ➔ Users and groups, assign only that one mailbox user Result: Only that user account can sign in and grant the app access to their mailbox—no Exchange PS needed.
2. Use delegated SharePoint access with the new Sites.Selected permission • In Azure AD ➔ App registrations ➔ API permissions, add Sites.Selected (application) and grant admin consent • In the SharePoint admin center ➔ Active sites ➔ Select your site ➔ Permissions ➔ API access, grant the app one of the site-level roles (Read, Write, or Full Control) Note: The “API access” UI for Sites.Selected is rolling out and may be in Preview. Otherwise you’d fall back to Graph/PowerShell.
3. Leverage Teams Resource-Specific Consent in the Teams Admin Center • Build your Teams app package with RSC scopes in the manifest • In Teams Admin Center ➔ Teams apps ➔ Manage apps, upload it to your org’s app catalog • In Teams Admin Center ➔ Teams apps ➔ Permission policies, ensure user/team owners are allowed to install custom apps • A Team owner then installs your app in that single team (including private channels) and implicitly consents for that team only This avoids Global-Admin PowerShell, since the Team owner is the resource admin in RSC.

If you truly need a headless, app-only solution scoped to exactly one mailbox or one team, currently you must use Exchange Online PowerShell (for Application Access Policies) and Teams/Graph PowerShell (for RSC). Otherwise the delegated-consent pattern above is the easiest no-PowerShell path.

References

• Restrict mailbox access (Application Access Policy) – https://learn.microsoft.com/graph/auth-limit-mailbox-access

• Teams Resource-Specific Consent – https://learn.microsoft.com/teams/platform/graph-api/rsc/resource-specific-consent

• Microsoft Graph permissions overview – https://learn.microsoft.com/graph/auth/auth-concepts#microsoft-graph-permissions

• Sites.Selected site-scoped permission – https://learn.microsoft.com/graph/permissions-reference#sitesselected

• Enterprise app user/group assignment – https://learn.microsoft.com/azure/active-directory/manage-apps/assign-users-and-groups-applications

If the answer is helpful, kindly upvote it. If you have extra questions about this answer, please click "Comment".

Answer 2

No, there isn't any UI. There was some effort to bring better scoping controls to the Entra portal experience, but no official commitment/release dates. For the time being, management is done via PowerShell, or the underlying REST methods.

The alternative for your scenario would be to use delegate permissions, where the effective access is determined based on the user you are running with. I.e. the user's own mailbox (and potentially shared mailboxes he's been given access to), any Groups/Teams/Sites he's a member/owner of, and similar for any other resource.

Answer 3

There is no purely graphical alternative in the Azure Portal or Microsoft 365 Admin Center that provides the same fine‑grained scoping as:

• Exchange Online application access policies for a single mailbox, or
• Teams Resource-Specific Consent (RSC) for a single team and its associated resources.

For least‑privilege scoping, the supported approaches are exactly the ones already identified:

1. Limit mailbox access
   • Use Exchange application access policies to restrict an app with Mail.Read/Mail.ReadWrite/Calendars.Read/Calendars.ReadWrite to specific mailboxes. This is explicitly called out as the way to limit an app to particular mailboxes instead of tenant‑wide access.
   • These policies are configured via PowerShell; the context does not describe an equivalent GUI path.
2. Limit Teams/SharePoint access
   • For Teams data, use resource-specific consent (RSC) so the app only has access to the specific team or chat where it is installed, instead of org‑wide Graph permissions.
   • RSC permissions are:
     • Declared in the Teams app manifest (authorization section with RSC scopes, and webApplicationInfo for the Entra app ID).
     • Granted when a team owner installs the app in that team.
   • RSC is not configured in Microsoft Entra ID; it is managed via the Teams app manifest and Teams client/admin experiences, not via a central GUI equivalent to Exchange application policies.
3. SharePoint site scoping
   • For SharePoint, the equivalent to RSC is using Sites.Selected application permission and then granting the app access only to specific site collections.
   • This is also an admin‑level configuration; the context describes it as part of an RSC‑style pattern, not as an end‑user GUI alternative.
4. General guidance / alternatives
   • Best practices recommend using RSC and other scoped permissions (Exchange application policies, Sites.Selected) to implement least privilege and avoid tenant‑wide access.
   • There is no alternative described in the context that would allow scoping to a single mailbox and a single team without using these admin‑level mechanisms.
   • If internal admin skills are limited, the practical path is:
     • Have a tenant admin register the app in Microsoft Entra ID and configure the required Graph permissions.
     • For Teams, define RSC permissions in the Teams app manifest and have a team owner install the app in the specific team.
     • For mailboxes and SharePoint, have an admin apply the appropriate application access policy and Sites.Selected configuration.

Without those admin‑level steps (PowerShell or equivalent admin configuration), the app will either not get the required permissions or will have to use broader, less‑scoped permissions, which conflicts with the least‑privilege model described in the documentation.

---

References:

• Develop application permissions strategy
• Understand the permissions and information accessed by Teams apps
• Overview of Microsoft Graph permissions
• Permissions in Teams app
• Best practices for using Microsoft Graph permissions
• Understanding Resource Specific Consent for Microsoft Graph and SharePoint Online
• Grant RSC permissions to your app