python-social-auth
token validation for azure AD backend
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 ?
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 https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/609#issuecomment-524434987
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 aud is my AAD app that I use to get the id token so I need to decode it.
Besides, if the token is not aimed for us, then do not decode it at all. But if we decode the token in python, then (I think) it should be verified.
On Thu, Mar 26, 2020 at 12:43 PM Björn Dalfors [email protected] wrote:
@sdementen https://github.com/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.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/python-social-auth/social-core/issues/109#issuecomment-604383544, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ6S5VECWAEWGWSFE454ULRJM5X3ANCNFSM4DRJ6ISA .
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.
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.
Can't the same logic as in AzureADB2COAuth2 be used with this backend as well?
