So can we or can we NOT parse access token?

Question

Hi, I've implemented the auth code grant flow. In my flow the scope specified is scope=https://custom-app.com/role And after the access token is issued the aud is correspondingly points to my application: "aud": "https://custom-app.com Now, can you please help me decipher the warning from the https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow#refresh-the-access-token documentation page:

Warning
Don't attempt to validate or read tokens for any API you don't own, including the tokens in this example, in your code. Tokens for Microsoft services can use a special format that will not validate as a JWT, and may also be encrypted for consumer (Microsoft account) users. While reading tokens is a useful debugging and learning tool, do not take dependencies on this in your code or assume specifics about tokens that aren't for an API you control.

From what I understand - this particular warning is not applicable to me, as the token issued is for my application (because it has the corresponding aud). But still it's either a language barrier or the warning is worded in a confusing way. Hence: can I decode access token and rely on its structure as described at https://learn.microsoft.com/en-us/entra/identity-platform/access-token-claims-reference ? I need this token to authenticate the user (know who they are) and authorise them (know what roles they have), and at the moment - the token contains all details I need. Thank you :-)

Answer 1

It depends on the app type/auth flow used. The statement above is a bit generic, as it tries to summarize things. You can, and should validate tokens when "you" are representing the resource API. Quote:

Only in specific scenarios should applications validate a token:

• Web APIs must validate access tokens sent to them by a client. They must only accept tokens containing one of their AppId URIs as the aud claim.
• Web apps must validate ID tokens sent to them by using the user's browser in the hybrid flow, before allowing access to a user's data or establishing a session.

APIs and web applications must only validate tokens that have an aud claim that matches the application. Other resources may have custom token validation rules. For example, you can't validate tokens for Microsoft Graph according to these rules due to their proprietary format. Validating and accepting tokens meant for another resource is an example of the confused deputy problem.

There are in fact multiple documents that guide you over the process of validating an access token: https://learn.microsoft.com/en-us/entra/identity-platform/claims-validation

Even outside of these scenarios, decoding a token can provide useful troubleshooting information, but it's not something that you should rely on (not always possible, and "your" validation has zero effect on the actual validation from the resource API).