What's the difference between User.Read and OpenID+Profile+Email scopes

Question

Does User.Read "contain" the permissions email openid and profile? I've found that apps that are requesting the 3x scopes, can instead accept just the User.Read permission and still function equivalently

At work I'll get requests from the business to help them setup SSO using OIDC, and I'm not actually sure what permissions I should be giving them. Seems like either option works but I'd like to better understand what's happening

See my observations below:

• I've created a basic Function App, and configured it to use OpenID Connect Image

• My App Registration already has the User.Read permission with admin consent, so when I log into my Function, there's no issue. Image

• However, after removing the User.Read permission and logging in, I now get a permissions request prompt Image

• And after consenting to the permissions, I can now see that email openid and profile permissions were added Image

• Even more interesting, the permissions in the request prompt correlate to openid and offline_access, but offline_access wasn't added, while email and profile weren't in the request

I did find a similar question, but the accepted answer doesn't seem to align with what I see here

Answer 1

User.Read is a scope intended to be used when requesting an access token for the Microsoft Graph API. It grants privileges to read the profile of the signed-in user only. A separate call to the Microsoft Graph API is required to retrieve the profile.

openid, email, profile and offline_access are OpenID Connect scopes:

• openid is used to request an id token.
• offline_access is used to request a refresh token which can later be used to get a new access token.
• email to request an email claim.
• profile to request several user claims (Eg.preferred_username).
• Both email and profile can be used to augment information available in the UserInfo endpoint, however, it is recommended to use the id token which is already a superset of the information available at the aforementioned endpoint.

Hope this helps.

Answer 2

Generally I would favour the OAuth standard design where fields like these are Personally Identifiable Information (PII). So each app should only use the smallest scope it needs, as an information disclosure best practice. See also this Curity article.

• Name
• Email
• Phone
• Address

The Graph API can also be used with standard scopes, as in step 11 of this blog post of mine, where I wanted to get hold of user info in an API. So if this works for you I would prefer it. Personally I also prefer standard scopes so that my application code is portable.

Microsoft's design is based on each API requiring a different access token, the resource indicators spec. It is interesting, though perhaps not always intuitive. I am no expert on Azure AD though, and there may be some intended usage I do not understand.