Azure-docs: Clarification on ID Token validation meaning

[smoms]

When you write "This token is known as the ID token and contains basic information about the user, such as the user display name. If you plan to use any data provided by this token for any purposes, you need to make sure this token is validated by your backend server to guarantee that the token was issued to a valid user for your application." just to make sure this is meant to use more logic on the token to "validate further" the user? I mean to do in a backend service something like:

string owner = ClaimsPrincipal.Current.FindFirst(ClaimTypes.NameIdentifier).Value;
IEnumerable<Todo> currentUserToDos = db.Todoes.Where(a => a.Owner == owner);
...
For me just to be sure that the msal lib itself validates the token (its signature), at least i can be sure the claims are originals. Right?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 4c6d2219-cb28-5527-1079-6e3195cad282
• Version Independent ID: 70c2aad0-6883-51a9-fed7-01be62302483
• Content: Azure AD v2.0 JavaScript single-page application (SPA) guided setup
• Content Source: articles/active-directory/develop/tutorial-v2-javascript-spa.md
• Service: active-directory
• Sub-service: develop
• GitHub Login: @navyasric
• Microsoft Alias: nacanuma

[KetanChawda-MSFT]

@smoms Thank you for your feedback! We will review and provide an update as appropriate.

[navyasric]

@smoms MSAL.js library is a client library which just returns the tokens. It does not perform the validation of the tokens. Your backend will need to validate the tokens.

[smoms]

@navyasric thanks. But my question is more subtle. Does MSAL validate (at least) the signature of the token? Of if i send it a signature-tampered-with token then for MSAL is still ok?
Beside that i understand that further validations need to be done in the backend.

[navyasric]

@smoms - MSAL.js does not validate the token(even signature). It does perform state and nonce match checks to mitigate the risks.

[shashishailaj]

@smoms MSAL is a library to facilitate token retrieval . Ideally if Signature tampering is done , the application back-end would fail to validate the token as it would not match the same signature with which the Azure AD STS system had signed it . Hence any such attack would not be feasible. Hope the information provided above by @navyasric helped as well. We will close this issue by end of day . In case you have any further queries , please let us know and we will gladly continue the conversation. Alternatively you can always open a new issue and we will be happy to help .

Thank you.

[smoms]

@shashishailaj @navyasric thanks. Your statements are bit in contrast with rules. ID_Token is target to client-app NOT to backend. As such client-app MUST validate the ID_token. Why MSAL is not doing that?

https://auth0.com/docs/tokens/guides/id-token/validate-id-token#verify-the-signature
https://auth0.com/docs/tokens/id-token
https://stackoverflow.com/questions/49909894/should-openid-connect-id-tokens-be-validated-in-the-browser
https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation

[shashishailaj]

@smoms I believe it is designed in this way. And I think I mentioned application back-end in a confusing way . What I meant, is that the validation logic would need to written within the client application by the dev and the library may not handle it . I would let @navyasric comment further on that.

@navyasric Could you please provide clarification on the same ?

[daveba]

@navyasric any follow-up to @shashishailaj question to provide more clarification?

[CelesteDG]

reassign:@negoe Reassigning to Neha.

[hpsin]

Hey all - having your front end app validate the token is not going to help. We call that client side security and it doesn't work. What's the benefit of having the JS running in the attackers browser do the validation? They'll just edit it out or call your API directly with the tampered token.

Your backend app that accepts the token needs to validate the token - that's a hard and fast rule, you can't rely on your front end to do this. @smoms does that help?

[smoms]

@hpsin well this depends on the OIDC flow. And the spec is clear that client MUST validate token:
https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation

It is different discussion that malicius devs are free to create "bad" apps for their (bad?) users; however still the app will never be able to access backends.
On the other end "good" and protected apps should make sure that tokens are valid for their users before proceeding.
https://auth0.com/docs/tokens/concepts/id-tokens

So I think yours is not a generically valid reason.

[hpsin]

Note the requirements you linked:

If the ID Token is received via direct communication between the Client and the Token Endpoint (which it is in this flow), the TLS server validation MAY be used to validate the issuer in place of checking the token signature. The Client MUST validate the signature of all other ID Tokens according to JWS [JWS] using the algorithm specified in the JWT alg Header Parameter. The Client MUST use the keys provided by the Issuer.

We trust the TLS connection in SPA scenarios. There is no value in having the client-side application validate the tokens, because the "bad user" of the "good app" will simply edit around that code. The app JS isn't protecting anything that a malicious user doesn't already have access to, and if an attacker has taken over the TLS connection the user is already compromised anyway (in particular because the attacker could also just edit out the validation code).

I think you and I agree:

however still the app will never be able to access backends.

Can you describe the attack you're protecting against here with this statement?

On the other end "good" and protected apps should make sure that tokens are valid for their users before proceeding.

[smoms]

The specification states that app must validate the token. So I still expect the libraries does that job. Also because a "good app" cannot(*) be compromised by a malicious user. I struggle to see how e.g. a Web App can be compromised on the fly.

(*)The Implicit Grant flow threats are well documented:
https://tools.ietf.org/html/rfc6819#page-37

In such description the threats are related to other types of attacks. So the assumption is kept, that for such flow the client must validate the token.

[mmacy]

Thanks handling this one @hpsin! Reassigning to you. #reassign:hpsin

[hpsin]

Hey @smoms , thanks for the conversation.

Let me lay out some assumptions here, that the MSAL.js library also contains, and see if they match yours.

1. The library is being used in a SPA app, a blob of JS sent to the user's browser and executed there.
2. You have another service (appID irrelevant) that accepts ID tokens requested by the SPA app and sent from the SPA app to the service. You wish to protect this back end service.

The assumption implicit here is that the app is executing in the users browser, completely under control by the user (e.g. using the F12 tools). If that user wishes to abuse your service, they have a variety of ways to do so, none of which are impeded by validating the token within the SPA's code.

For the reason above, there is no value in validating the token within the SPA app. It accomplishes nothing. We have no plans to add validation for code that runs in the context of the users browser, as it provides no security benefit.

None of the threats outlines in the RFC you link are impeded by running token validation within the users browser either. They all related to token exfiltration attacks that persist regardless of the flow used to push tokens to the SPA or validation required. In fact, they call out the same issue that we do - you cannot trust the front end to do token validation, as token injection attacks are a threat. you must protect yourself against token injection attacks by doing validation of the token on the server side.

[smoms]

@hpsin thanks. I will compare with other libraries. You can close it. thanks

[mmacy]

Thanks @hpsin and @smoms, closing now. #please-close