Scopes being removed when getting a token

Question

Here are the steps I've taken:

1. Authorize here: https://login.microsoftonline.com/common/oauth2/v2.0/authorize , with certain scopes in the querystring, like "User.ReadWrite.All Group.ReadWrite.All Chat.Read Files.Read.All"
2. After successful login, get the user token from here: https://login.microsoftonline.com/common/oauth2/v2.0/token with the "authorization_code" grant type.
3. The return response includes the token and scopes, but the scope only has "Files.Read.All" with everything else missing. I try to hit '/me' with the token, but it fails.

What causes the scopes to be removed after auth? I even added them to the app directly in the Azure portal, and they still get removed.
Thanks!

Answer 1

If the affected account is a Microsoft (personal) account you won't get scopes Chat.Read and User.ReadWrite.All since they are not supported for such type of account.

To be able to hit the /me endpoint you need User.Read or User.ReadWrite permission. If already consented they may be included in the token response regardless of the requested scope.

Answer 2

@TerryMatula-6253, Ideally the scopes should not get removed in any case. When using v2.0 endpoint of AAD, even the scopes are not required to be specified to the application and they can only be specified in request and that gets added incrementally. You can also use the /.default which would add all the available scopes that have specified in the app registration.

I tested your scenario right now and it worked for me.

I used the following request to get a code from Azure AD's authorize endpoint:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id={app-id}&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A1234&response_mode=fragment&scope=openid%20openid%20offline_access%20User.Read%20Files.Read.All&state=12345

Once the code was issued, I called the /token endpoint using Postman and I got the response with all the scopes in the token.

One more thing to check here is, when you are specifying the scopes in either the request or in the app registration and if the scopes are being requested by any user (in case the admin has not consented them for the entire tenant), then each time a new scope is being requested for in the token, a consent page would come up asking for the user to consent for that new scope. In your case, did the consent page come up and did you consent for that new scope. If not then the problem might be there as why the scope being added is not being to get consent from user.

You can check here, to understand which all permissions the users have consented for:

Hope this helps. Do let us know if there are any more queries around this so that we can help you further. Also, please do not forget to accept the response as Answer; if the above response helped in answering your query.

Answer 3

Can you provide the complete authorize endpoint url?

Answer 4

@alfredo-msft-identiy

Here's the flow. First we direct the user to authorize:

 https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=****&redirect_uri=https%3A%2F%2F****%2Fauth%2Fcallback&scope=Group.ReadWrite.All+Chat.Read+Files.Read.All+Sites.Read.All+User.ReadWrite.All+offline_access&response_mode=form_post&response_type=code

We get a callback with:

 'code' => '****10f24',
 'state' => '***'

We then hit the token endpoint to exchange for an access token:

 POST https://login.microsoftonline.com/common/oauth2/v2.0/token

Request:

 'client_secret' => '****',
 'code' => '****10f24',
 'grant_type' => 'authorization_code',
 'redirect_uri' => 'https://****/auth/callback'

And this is the response that we get:

 'token_type' => 'Bearer',
 'scope' => 'Group.ReadWrite.All Files.Read.All User.Read',
 'expires_in' => 3600,
 'ext_expires_in' => 3600

Thanks!