Assertion failed signature validation when trying to acquire a token to issue REST calls to dev ops on behalf of a user

[flixman]

Describe the bug
I have an azure app, having granted the 'impersonate_user' permission, that needs to be able to perform calls to azure devops on behalf of the user. Instead of getting a token allowing me to do so, I get an error. Am I missing a permission on the app, am I doing something wrong, or this is a bug?

To Reproduce
Just use the following snippet with the correspondent access token, client_id, client_secret and tenant parameters.

import msal
confidential_client = msal.ConfidentialClientApplication(
            <client_id>,
            authority="https://login.microsoftonline.com/<tenant>",
            client_credential=<cliend_secret>)
devops_token = confidential_client.acquire_token_on_behalf_of(
            user_assertion=request.headers.get("X-Ms-Token-Aad-Access-Token"),
            scopes=["499b84ac-1321-427f-aa17-267ca6975798/user_impersonation"])

Expected behavior
A token in that I can use to authenticate to azure devops.

What you see instead
The error invalid_grant and the description"ADSTS50013: Assertion failed signature validation. [Reason - The provided signature value did not match the expected signature value., Thumbprint of key used by client: '8D2D57A353960E3FF9DAF6F018D82F40ED95CCC7', Found key 'Start=01/30/2022 23:06:14, End=01/30/2027 23:06:14']."

The MSAL Python version you are using
1.17.0

[rayluo]

Your calling pattern seems about right. I can't tell whether it was some configuration issues. Some reference materials for you:

• A similar question on StackOverflow https://stackoverflow.com/questions/67400354/aadsts50013-assertion-failed-signature-validation-reason-the-key-was-not-fo
• The full calling pattern is also demonstrated in MSAL Python's test script https://github.com/AzureAD/microsoft-authentication-library-for-python/blob/1.17.0/tests/test_e2e.py#L556-L583

[KanishkaB]

@flixman - You have a python web app that needs to access the azure dev ops API. You have deployed this app on azure app service and are currently using the built in authentication feature of App Service aka EasyAuth.
The value of the access token generated from EasyAuth is actually an "authentication code" and when the resource is set, the EasyAuth module exchanges this “authentication code” at the /token endpoint of the Azure Active Directory, to get an access token. We ran couple of tests at your end and figured out that the scope - user_impersonation was not set at the resource level.

Work Around - To achieve this we need to set the resource using the Azure Resource Explorer.

1. Navigate to the Resource Explorer from the App Service.
2. Navigate config > authsettings and click on Edit.
3. Update the additionalLoginParams to ["resource=<Name/ID of the resource>"]
   Once this is set you should be able to access the Azure dev ops API.

Recommendation - we highly recommend you to use MSAL python in your application code so that the authentication can be handled at the application level This Web application will use MSAL for Python to sign-in a user and obtains an Access Token for API ( Azure dev ops in your case ) from Azure AD. The Access Token will prove that the user is authorized to access the API endpoint as defined in the scope. .You can refer to the below sample for reference
GitHub - Azure-Samples/ms-identity-python-flask-webapp-call-graph: Python Flask web application that leverages MSAL Python to get an access token to call MS Graph API
Please let us know in case you have any further questions or queries and we will be happy to answer.

[bryanidsts]

Even after doing this, calling https://graph.microsoft.com/v1.0/me with Bearer [request.headers.get("X-Ms-Token-Aad-Access-Token")] works fine, but trying to do acquire_token with on_behalf_of still throws the above error

[rayluo]

Even after doing this, calling https://graph.microsoft.com/v1.0/me with Bearer [request.headers.get("X-Ms-Token-Aad-Access-Token")] works fine, but trying to do acquire_token with on_behalf_of still throws the above error

I happen to play with Easy Auth since Tuesday, and now have a better understanding to this topic. I believe the access token obtained by App Service's built-in authentication (a.k.a. Easy Auth) is for the downstream resource or MS Graph. Such kind of token is not suitable to be used in MSAL's On-Behalf-Of for your web app.

@bryanidsts , in your case, it sounds like you have already followed the "work around" in the earlier answer and get it working, then you might as well stick with what you already have.

Alternatively, based on the aforementioned answer's "Recommendation - we highly recommend you to use MSAL python in your application code so that the authentication can be handled at the application level", you can try to switch to use MSAL and do it the MSAL way. This is a Python web app sample that can be deployed to App Service, and this is some quick notes on how to deploy it to App Service.

[meyerovb]

@rayluo msal is to get you a token u can use downstream. If u ALREADY have a token, ala easy auth x-ms header, msal just throws an error no matter how u try it. U need to just pass that token directly to the downstream. With Java sqlserverclient u can pass the auth token directly to it. But not for Java graphserviceclient, that expects an authenticator from msal, not a final token. I have a whole other ticket for that lol.

[rayluo]

1. msal is to get you a token u can use downstream

Correct. And that was what the earlier answer above recommended to use (instead of Easy Auth).

2. If u ALREADY have a token, ala easy auth x-ms header, msal just throws an error no matter how u try it. U need to just pass that token directly to the downstream. With Java sqlserverclient u can pass the auth token directly to it.

Also correct. Then you do not have to use MSAL in that situation.

3. But not for Java graphserviceclient, that expects an authenticator from msal, not a final token. I have a whole other ticket for that lol.

So, you still need a token that you do NOT ALREADY have. Then back to square one. LOL. Have joking aside, I still believe you should either do Easy Auth alone, or MSAL alone (which is still easy enough - the key part is just around 50 lines of code). Mix-and-matching Easy Auth's token with MSAL's On-Behalf-Of flow does not seem to work.

P.S.: Please keep this conversation around how to use MSAL in App Service, and save your project-specific topic for your "whole other ticket". :-)

[bryanidsts]

@rayluo well seeing that I have your attention, now that I actually finally understand absolutely everything about these tokens and how the different language libraries use them.... u have any feedback on this showstopper bug i just ran into? It's regarding aad scope so yeah, kinda related to msal :)