Hello, is the issue handled somewhere?
If not, I think it could be better to remove the support for AAD than to keep an insecure version, or at least add a warning when using it

@sdementen as it turns out the token validation fails when trying to validate a token that wasn't issued for your application. You can't validate tokens that are issued for say graph for example. This is by design. However, if you set a custom scope for your application in Azure AD application configuration, validation will work as expected.

See AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet#609 (comment)

Again: Stop looking at access tokens if they're not for you to look at. Easy way to know? The aud claim will match something that you own if they're for you. If it doesn't match, never look at it.

NOTE: However if you set a custom scope for your application you can no longer use the tokens to communicate with other backends such as graph, since the tokens are for your apis.

I am using the id_token to identify the user (so I am indeed looking to a token but not an access token, but an id token which is OK I think as use).
However, the id_token is not verified (jwt_decode(id_token, verify=False)) and therefore anyone could impersonate by forging an id_token, correct ?

if no, I am still missing something in the picture (and sorry for that!)

@sdementen first off; i'm no expert, results may vary ⚠️

What is the token scope? (what does the 'aud' claim say in the id token?)

You should never use a token issued for another service to authenticate with your application. ID tokens that are issued for MS services such as graph, etc, should only be used for these services, and whether the tokens are forgable or not should not be your concern.

The tokens should be used to access microsoft service endpoints and get a user from them. You can then use a custom pipeline step map information to map to a user within your application.

don't take my word for it though.

The same issue, I don't think it's the right behavior.

The documentation doesn't mention anything about usage, but it states that it can be used with the REST API. There are pipelines that link to the user. However, without verification, one can authenticate as any user.

@omab What's the status on this issue, why was it closed? Cheers

For myself, I reworked the user_data method, which instead of decoding the jwt token, goes and retrieves information from https://graph.microsoft.com/v1.0/me using the access token. I can submit a pull request.

I think the docs would benefit from some clarification around this, especially in the context of building One Page web apps using Client-side Flow with MSAL js library.