A dune-grass nursery portal reads the signed-in grower’s profile with User.Read, while a nightly job must read every grower as the app itself with User.Read.All. How should the developer map those permission types on the identity platform?
Select an answer to reveal the explanation.
Short Explanation
Signed-in grower? That’s delegated—permissions ride along as scopes. Nightly job with no user? That’s application permissions showing up as roles.
Full Explanation
Map permissions to the caller model. The dune-grass nursery portal acts for a signed-in grower, so User.Read is a delegated permission. Delegated grants appear in the access token’s scp claim and authorize Graph only for what that grower can already see (themselves, for User.Read). The nightly job has no user context, so User.Read.All must be an application permission. Application permissions appear in the roles claim and require admin consent; the job authenticates with client credentials as the app.
Treating both calls as application permissions, then renaming User.Read at runtime for the portal, fails conceptually. Application permissions do not become delegated by renaming strings in your code. The portal needs a user assertion and delegated scopes; inventing a rename does not create an scp claim or a signed-in subject.
Using User.Read.All as a delegated scope for both callers fails least-privilege and architecture. A nightly daemon still has no user to delegate, and stretching “admin consent covers the portal” does not turn an unattended job into a delegated call. The portal also should not request directory-wide read if it only needs the signed-in grower’s profile.
Issuing shared access signatures against Microsoft Graph fails because Graph is not Azure Storage. SAS is a Storage data-plane credential model; Graph authorization is Entra tokens with delegated or application permissions. SAS cannot substitute for Graph OAuth scopes.
Exam caveat: the same permission name can exist in both models (for example User.Read.All), but the token claim and consent path differ. Do not assume a delegated admin consent automatically grants application permissions to a daemon.
Operational check: for the portal, inspect the access token and confirm scp contains User.Read (or the expected delegated scopes). For the nightly job, confirm roles contains User.Read.All, that admin consent is recorded on the app registration, and that the token audience is Microsoft Graph.