Microsoft Azure AD JWT Token is missing Scope information

Question

question

ManuNair-1769 asked Feb 3, '21 BalakrishnaSudabathula-2499 answered Mar 19, '21

Microsoft Azure AD JWT Token is missing Scope information

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.

azure-active-directory

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Answer 1 · 2021-02-03T06:32:23.947Z

amanpreetsingh-msft answered Feb 3, '21 SayakMukhopadhyay-4836 commented Feb 11, '21

Hi @ManuNair-1769 · 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.

· 5

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

ManuNair-1769 · Feb 03, 2021 at 07:51 AM

Thanks @amanpreetsingh-msft for the answer. So you mean to say that if we use .default for scope, then all the permission will appear in the roles claim even though client app has only one permission? If that is the case what will be the best option for me to get only permitted roles in the token?

0 ·

amanpreetsingh-msft ManuNair-1769 · Feb 03, 2021 at 08:29 AM

Hi @ManuNair-1769 · The /.default scope returns only those permissions which are present under API permissions blade of the application whose client_id you are using to acquire the token. If underneath the API permissions blade, you have both API.READER and API.WRITER permissions added, using /.defaults scope you will get both permissions. If you remove API.WRITER permission and keep only API.READER permission under API permissions blade, you will get only API.READER permission in the roles claim with /.default scope.

If you previously added both permissions, make sure the admin consent is revoked as well as the permission is removed for API.READER permission from the API permissions blade and try acquiring new token.

0 ·

ManuNair-1769 amanpreetsingh-msft · Feb 03, 2021 at 06:28 PM

Hi @amanpreetsingh-msft Yes i had added both permissions to the client. But then I removed the WRITER permissions from the client without removing the admin consent.

"If you remove API.WRITER permission and keep only API.READER permission under API permissions blade, you will get only API.READER permission in the roles claim with /.default scope."

As i mentioned before, only API.READER permission is the one which the client app possess.

0 ·

Show more comments

SayakMukhopadhyay-4836 amanpreetsingh-msft · Feb 11, 2021 at 11:33 AM

I am doing something similar. I had an app registration that was exposing multiple scopes. I had a web app with auth code flow having a couple of scopes as permissions. Things work great. Now I have a daemon app that wants to get permissions from the same app registration. Obviously I tried by giving the daemon app delegated permissions from my scope exposing app and obviously that didn't work. I was giving the /.default scope while accessing the access token and I was able to receive the access token but that access token neither had scp nor roles.

The docs say that I have to edit the manifest (since I am using a B2C tenant) to add to appRoles which seems like a pain. Isn't there an easier way to sync the API permissions I expose for frontend apps and appRoles needed for daemon like apps?

0 ·

Answer 2 · 2021-02-03T06:20:00.897Z

soumi-MSFT answered Feb 3, '21 ManuNair-1769 commented Feb 3, '21

Hello @ManuNair-1769, 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://docs.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps

For more information on Roles and Scopes: https://docs.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.

· 1

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

ManuNair-1769 · Feb 03, 2021 at 06:56 AM

Thanks @soumi-MSFT for the answer. That explains the answer for Issue 1. But issue 2 is not yet clear. I have assigned only one permission which is API.READER to the client APP. However, I see both API.WRITER and API.READER in the roles claims.

0 ·

Answer 3 · 2021-03-19T07:40:23.07Z

BalakrishnaSudabathula-2499 answered Mar 19, '21

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?

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

question