Microsoft Azure AD JWT Token is missing Scope information

Question

I am facing few issues with respect to oauth2 in azure.
I have configured App registration exposing two scopes something like API.READ.ALL and API.WRITE.ALL
Also i have added two APP Roles API.READER and API.WRITER

Now i have registered the client APP assigning it the permission of API.READ.ALL and API.READER

Issue 1.
Now when i generate the token, token doesn't contains scp(scope) element or any other element denoting the scope.

Issue 2.
In the roles claim i see both API.READER and API.WRITER roles even though i expected only assigned API.READER role

This is how i use to generate token from POSTMAN
https://login.microsoftonline.com/\<tenantId>/oauth2/v2.0/token
clientId: <client app id>
client secret: <client secret>
scope: api://<app id>/.default
Grant Type: Client Credentials
Client Authentication: Send Client credentials in the body

This is the token receieved after decoding it in jwt.io

{
"aud": "<app id>",
"iss": "https://login.microsoftonline.com/<tenantId>/v2.0",
"iat": 1612310376,
"nbf": 1612310376,
"exp": 1612314276,
"aio": "<value>",
"azp": "<client id>",
"azpacr": "1",
"oid": "<value>",
"rh": "<value>",
"roles": [
"API.WRITER",
"API.READER"
],
"sub": "<value>",
"tid": "<tenantId",
"uti": "<val>",
"ver": "2.0"
}

See there is no value for the scope in the token and also roles contains both the roles. Please advice what needs to be done.

Answer 1

Hi @Manu Nair · Thank you for reaching out.

Since you are using Grant Type: Client Credentials, the token is acquired under application context. In case of which, the permissions are included in roles claim. The SCP (scope) claim is available only when the token is acquired under user context using OAuth flows such as Authorization Code grant, Implicit Grant, ROPC etc.

When acquiring token under application context, we can only use /.default in the scope parameter. You can NOT specify api://<app id>/API.READER as scope in this case as this is possible only when the access token is acquired under user context. When a scope with /.default is added to the authentication request, all application permissions added and consented, under api permission blade of the application are included in roles claim within the access token.

In short, the behavior you have mentioned in both the issues is as per design and can not be changed.

-----------------------------------------------------------------------------------------------------------

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

Answer 2

Hello @Manu Nair , thank you for reaching out. You are not seeing any scp(scope) property in your JWT just because, you are using Client_Credentials flow of OAuth 2.0. Client_Credentials flow of OAuth 2.0 is to fetch access-tokens in applications context and for permissions required for client_credentials to work are called application permissions (found in the api permission section in-app registration). These application permissions when added to the JWT gets added under the role property. Hence in your case, you can see the roles property with the corresponding values. If you need the scp property to fetch the permissions, you need to use the Auth-Code grant flow of OAuth 2.0 as that's the flow used to fetch access-tokens in users' context and the set of permissions used are delegated permissions.

Now coming to the fact that why both the app roles API.READER and API.WRITER are added to the roles property of your JWT. When you create an App Role of type "Application", they become a part of your application permissions. Now if you have added both the listed app roles above to your application's api permission section and provided admin consent, then both of those app roles would be listed in your JWT. This is expected behavior.

You can read more on App Roles and their assignment to users and applications here: http://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps

For more information on Roles and Scopes: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent

Hope this helps.

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

Answer 3

Below is the latest update from Microsoft ,

UPDATE: November 2020
[appRoles] Azure AD application attribute is now available (in preview) in the portal UI, so alternatively you could change and view the application roles through Azure portal UI settings.

It is not a good idea to use AppRoles to get the API Permissions. If you go with authorization code grant flow that's the flow used to fetch access-tokens in users' context .

What is the best wat to get the Scope Claim using application context with out the AppRoles?