Microsoft Graph: App registrations & API permissions vs requested scopes

0
votes

What is the connection between "API permissions" that I add in the app registration and the actual requested scopes?

I noticed that I still can request all my desired permissions, but can leave this registration (besides the "application" permission) empty:

enter image description here

And this works:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=05f0df69-2f61-4b41-91ff-31656787f9d3
&redirect_uri=https%3A%2F%2F....azurewebsites.net%2Fids%2Foidc-signin-office365auth
&response_type=code%20id_token&scope=openid%20profile%20email%20User.Read%20offline_access%20User.ReadBasic.All
&response_mode=form_post
&nonce=...

Scopes:

  • openid
  • profile
  • email
  • User.Read
  • offline_access
  • User.ReadBasic.All

In the past I thought the requested scopes and the app permissions in the app registration must match, but this doesn't seem to be the case anymore.

My goal is to keep the app registration as small as possible.

This question might be somewhat related to this question.

1
azure-active-directorymicrosoft-graph-api

1 Answers

0
votes

It is a difference between v1.0 and v2.0 endpoint, when using v1.0 endpoint, we use resource instead of scope, all the permissions need to be listed in the API permissions.

When using v2.0 endpoint in your case, we can ask for the permissions dynamically. It does not matter if you add the permissions or not in the API permissions, when you add the permissions in the scope of the request url, the consent window will pop-up.

Reference - https://docs.microsoft.com/en-us/azure/active-directory/azuread-dev/azure-ad-endpoint-comparison#incremental-and-dynamic-consent

With the Microsoft identity platform endpoint, you can ignore the static permissions defined in the app registration information in the Azure portal and request permissions incrementally instead, which means asking for a bare minimum set of permissions upfront and growing more over time as the customer uses additional app features. To do so, you can specify the scopes your app needs at any time by including the new scopes in the scope parameter when requesting an access token - without the need to pre-define them in the application registration information. If the user hasn't yet consented to new scopes added to the request, they'll be prompted to consent only to the new permissions.