A botanical-garden inventory API is called by an internal SPA, and the team plans to reuse User.Read as the only scope. What should the security engineer configure on the inventory app registration instead?

First-party APIs should expose an application ID URI and define custom scopes so client applications request those scopes when calling your API. For the botanical-garden inventory API consumed by an internal SPA, the security engineer should expose an API on the inventory app registration, set an application ID URI, and define an application-specific scope such as access_as_user. The SPA then requests that scope and receives an access token whose audience is the inventory API—not a misuse of Microsoft Graph’s User.Read as if it authorized garden inventory operations.

Keeping User.Read as the API’s only exposed scope and granting the SPA Application.ReadWrite.All fails by concept: User.Read is a Microsoft Graph permission for reading the signed-in user profile, not a custom scope for your inventory API, and Application.ReadWrite.All is a high-privilege permission for managing applications. Publishing the inventory API only through Microsoft Entra Application Proxy so custom scopes are unnecessary fails because Application Proxy publishes on-premises web apps; it does not replace OAuth scope design for a first-party API registration. Replacing scopes with an Azure RBAC Owner assignment on the SPA’s resource group fails because Azure RBAC authorizes Azure resource actions and does not mint Entra access tokens with your API’s scopes.

Exam caveat: “Expose an API” plus application ID URI plus custom scopes is the standard Entra pattern for protecting your own API. Operational check: define the scope, authorize the SPA app to that scope, acquire a token with the inventory API audience, call a protected inventory endpoint, and confirm a token lacking that scope is rejected.