Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

token validation for azure AD backend #109

Open
sdementen opened this issue Jun 30, 2017 · 9 comments
Open

token validation for azure AD backend #109

sdementen opened this issue Jun 30, 2017 · 9 comments
Labels
stale Stale issues (closing soon)

Comments

@sdementen
Copy link
Contributor

Does the azure AD Backend validates the id_token and access_token sent by Azure AD?

In the code I see a decoded_id_token = jwt_decode(id_token, verify=False).

When I set to verify=True:

  • I get an exception "Token error: Signature verification failed" if I tamper with the id_token which is fine
  • I get an exception "Could not deserialize key data." if the id_token is real which is not OK

My questions:

  • shouldn't the "verify=True" be the default ?
  • how can I fix the "Could not deserialize key data" exception ?
@omab omab added the stale Stale issues (closing soon) label Mar 21, 2020
@omab omab closed this as completed Mar 21, 2020
@sdementen
Copy link
Contributor Author

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

@bj00rn
Copy link
Contributor

bj00rn commented Mar 26, 2020

@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.

@sdementen
Copy link
Contributor Author

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!)

@bj00rn
Copy link
Contributor

bj00rn commented Mar 26, 2020

@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.

@sdementen
Copy link
Contributor Author

sdementen commented Mar 26, 2020 via email

timthelion added a commit to auto-mat/do-prace-na-kole that referenced this issue Mar 17, 2021
@mike667
Copy link

mike667 commented Apr 29, 2024

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.

@bj00rn
Copy link
Contributor

bj00rn commented Apr 30, 2024

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

@mike667
Copy link

mike667 commented Apr 30, 2024

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.

@nijel nijel reopened this May 2, 2024
@bj00rn
Copy link
Contributor

bj00rn commented May 2, 2024

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.

@nijel nijel linked a pull request May 6, 2024 that will close this issue
11 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Stale issues (closing soon)
Development

Successfully merging a pull request may close this issue.

5 participants