AZURE oauth access token

Question

AZURE oauth access token

M.H.H de Haas 0

Hi All,

I have a basic APP configured in Azure portal with oauth enabled and when i try to retrieve a token i receive three parts, the access_token, refresh_token and token_id. The strange thing is that the access_token is someway hashed and i dont know how to decode it. The other refresh and id token are clear text and can be decoded normally with jwt.io.

Does someone has an answer on this behavior?

M.H.H de Haas 0 Reputation points

2023-12-20T10:55:32.1133333+00:00
The access_token looks like this but is not decodable

token_type":"Bearer","expires_in":"3599","ext_expires_in":"3599","expires_on":"1703073245","access_token":"PAQABAAIAAAAmoFfGtYxvRrNriQdPKIZ-GQh
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-20T13:57:48.64+00:00

Hi Thanks for the question
The response you show above looks like the response to a POST to the login.windows.net token endpoint (in other words a client has requested a token from Entra/AAD

The oauth spec supports two types of JSON Web Token (JWT) , signed which is base64 encoded, and encrypted also known as JWE or an "opaque token"

AAD/Entra does support encrypted tokens - however the app registration needs to be configured specifically to allow this - it's not the default (in so far as I'm aware)

It would be worth checking the related app registration here - for more info see this blog https://github.com/AzureAD/microsoft-identity-web/wiki/Token-Decryption
M.H.H de Haas 0 Reputation points

2023-12-20T14:16:26.7066667+00:00

Yes exactly this is the response of token retrieval and inside the JWT I see three parts access_token with value, refresh_token with value and token_id with value. The token_id value has the JWT access token and is base64 decodable, however the access_token is someway encrypted. Could it be possible that this encryption is applied only on the access_token and not on the id_token? For technical reasons we need to read the access_token from the oauth client application. How can we verify inside the Azure portal if this encryption is applied? we cannot find anything in the manifest that would do that. Thanks for the help
M.H.H de Haas 0 Reputation points

2023-12-20T15:06:28.8166667+00:00

Perhaps there is a way to request a token to /oauth2/token and instruct the endpoint to provide a normal jwt (not JWE encrypted), could we add a specific paramete/value to the POST request to enforce this from the oauth client application? note:we dont require JWE at the moment but would be something worth to investigate as well, not sure why it is doing this...
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-20T16:07:26.6566667+00:00

Hi --- The id token would be for the user login (open id connect) , the scope for this token is the client application. The access token would be the bearer token towards the downstream dependency (which I assume here is an API, but could be something else that's authorized through oauth)

So I would expect only the access token to be encrypted

I dont have a repro for this right now, but I would expect the App manifest manifest to contain the key configuration as per section https://github.com/AzureAD/microsoft-identity-web/wiki/Token-Decryption#in-the-azure-ad-portal
Without this Entra would not be able to encrypt the token

The manifest would be for the app that represents the downstream resource (the API I am assuming). I say this because usually you have two app registrations, one for the client app and one for the api (so one for each downstream dependency which is 1:1 related to that dependency). It's this app that provides the config for Entra to generate the access token (and populate the claims values)

I am making an assumption here that what you are seeing is indeed an encrypted token (given that Entra does support this as your assertion it's not a regular signed/base64 encoded JWT)
M.H.H de Haas 0 Reputation points

2023-12-20T19:26:24.9166667+00:00

inside the manifest i find this tokenEncryptionKeyId": null not sure what null would represent here
M.H.H de Haas 0 Reputation points

2023-12-20T19:28:15.0333333+00:00

I understand that encrypting the access token would secure the exchange of attributes but it would be nice if a customer could enable/disable JWE as not all client applications/API server support it, yet :-) but that of course they should ;-)
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-21T09:55:15.9866667+00:00

mmm OK if it's not been explicitly set to encrypt it may not be a JWE - or more precisely a JWE you could use.

Under certain circumstances Entra/AAD will issue an access token which is not a base64 encoded string. As far as I know the implementation details as to "how" they create the token in this instance are proprietary to Entra/AAD and not published.

However these tokens are meant for the platform (or other platform services) - I have come across scenarios in the past where the customer did not configure the app registration correctly or missed a scope (or sent the wrong scope) and instead of receiving an access token for their API they received an access token for graph (for example)

It would be worth going back to the flow your setting up and comparing it against one of the tutorial/examples to see if you missed anything

if you have the app registrations setup correctly , are requesting the token correctly and have not explicitly configured keys for a JWE then you should see a signed base64 encoded JWT which you can validate

There home page for the samples is here https://learn.microsoft.com/en-us/entra/identity-platform/sample-v2-code?tabs=apptype

if you're still stuck you may need to open a support case to troubleshoot (unless one of my identity colleagues here can comment)

Your answer

M.H.H de Haas 0 Reputation points

2023-12-20T10:55:32.1133333+00:00

The access_token looks like this but is not decodable

token_type":"Bearer","expires_in":"3599","ext_expires_in":"3599","expires_on":"1703073245","access_token":"PAQABAAIAAAAmoFfGtYxvRrNriQdPKIZ-GQh
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-20T13:57:48.64+00:00

Hi Thanks for the question
The response you show above looks like the response to a POST to the login.windows.net token endpoint (in other words a client has requested a token from Entra/AAD

The oauth spec supports two types of JSON Web Token (JWT) , signed which is base64 encoded, and encrypted also known as JWE or an "opaque token"

AAD/Entra does support encrypted tokens - however the app registration needs to be configured specifically to allow this - it's not the default (in so far as I'm aware)

It would be worth checking the related app registration here - for more info see this blog https://github.com/AzureAD/microsoft-identity-web/wiki/Token-Decryption
M.H.H de Haas 0 Reputation points

2023-12-20T14:16:26.7066667+00:00

Yes exactly this is the response of token retrieval and inside the JWT I see three parts access_token with value, refresh_token with value and token_id with value. The token_id value has the JWT access token and is base64 decodable, however the access_token is someway encrypted. Could it be possible that this encryption is applied only on the access_token and not on the id_token? For technical reasons we need to read the access_token from the oauth client application. How can we verify inside the Azure portal if this encryption is applied? we cannot find anything in the manifest that would do that. Thanks for the help
M.H.H de Haas 0 Reputation points

2023-12-20T15:06:28.8166667+00:00

Perhaps there is a way to request a token to /oauth2/token and instruct the endpoint to provide a normal jwt (not JWE encrypted), could we add a specific paramete/value to the POST request to enforce this from the oauth client application? note:we dont require JWE at the moment but would be something worth to investigate as well, not sure why it is doing this...
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-20T16:07:26.6566667+00:00

Hi --- The id token would be for the user login (open id connect) , the scope for this token is the client application. The access token would be the bearer token towards the downstream dependency (which I assume here is an API, but could be something else that's authorized through oauth)

So I would expect only the access token to be encrypted

I dont have a repro for this right now, but I would expect the App manifest manifest to contain the key configuration as per section https://github.com/AzureAD/microsoft-identity-web/wiki/Token-Decryption#in-the-azure-ad-portal
Without this Entra would not be able to encrypt the token

The manifest would be for the app that represents the downstream resource (the API I am assuming). I say this because usually you have two app registrations, one for the client app and one for the api (so one for each downstream dependency which is 1:1 related to that dependency). It's this app that provides the config for Entra to generate the access token (and populate the claims values)

I am making an assumption here that what you are seeing is indeed an encrypted token (given that Entra does support this as your assertion it's not a regular signed/base64 encoded JWT)
M.H.H de Haas 0 Reputation points

2023-12-20T19:26:24.9166667+00:00

inside the manifest i find this tokenEncryptionKeyId": null not sure what null would represent here
M.H.H de Haas 0 Reputation points

2023-12-20T19:28:15.0333333+00:00

I understand that encrypting the access token would secure the exchange of attributes but it would be nice if a customer could enable/disable JWE as not all client applications/API server support it, yet :-) but that of course they should ;-)
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-12-21T09:55:15.9866667+00:00

mmm OK if it's not been explicitly set to encrypt it may not be a JWE - or more precisely a JWE you could use.

Under certain circumstances Entra/AAD will issue an access token which is not a base64 encoded string. As far as I know the implementation details as to "how" they create the token in this instance are proprietary to Entra/AAD and not published.

However these tokens are meant for the platform (or other platform services) - I have come across scenarios in the past where the customer did not configure the app registration correctly or missed a scope (or sent the wrong scope) and instead of receiving an access token for their API they received an access token for graph (for example)

It would be worth going back to the flow your setting up and comparing it against one of the tutorial/examples to see if you missed anything

if you have the app registrations setup correctly , are requesting the token correctly and have not explicitly configured keys for a JWE then you should see a signed base64 encoded JWT which you can validate

There home page for the samples is here https://learn.microsoft.com/en-us/entra/identity-platform/sample-v2-code?tabs=apptype

if you're still stuck you may need to open a support case to troubleshoot (unless one of my identity colleagues here can comment)

Share via

AZURE oauth access token

Your answer