Issuer in access token from azure active directory is https://sts.windows.net when I'm expecting https://login.microsoftonline.com

13
votes

I'm trying to validate an access token obtained from azure active directory.

The I obtained the token from https://login.microsoftonline.com/{{my tennant guid}}/v2.0

however the issuer in the token that comes back is https://sts.windows.net//{{my tennant guid}}/ which doent match.

If I check that config at .well-known/openid-configuration the issuer is as expected https://login.microsoftonline.com/....

I've found a similar issue reported on git hub here https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/560

the outcome from this is to manually edit the manifest json in the application registration in AAD and set "accessTokenAcceptedVersion": 2

I've done this but it has made no difference.

I've also seen similar questions here on stack overflow but these are related to a difference in the tenancy guid - that is not the case here.

2
azureazure-active-directoryopenid-connectmsal
You edited the app registration manifest for the API right? That should change the token to v2.. – juunas
Yes I changed the manifest for both the client and the api – Twisted
Can you show the code you are using to acquire the token? – juunas
I've just prepared an example token to post using jwt.io and the token now contains the expected issuer. eg login.microsoftonline.com. strangely the audience has changed from api://myapi to my clientId Guid. I havent changed any of my code since posting the question so I can only assume that setting "accessTokenAcceptedVersion": 2 actually worked but took several hours to come into effect. – Twisted

2 Answers

12
votes

So seems that changing the acceptedTokenVersion to 2 in the manifest did change but it just took time to take effect.

And yes the audience is always the client id based on my tests in v2 tokens.

-1
votes

The issuer id looks ok at first glance - it is a logical url to represent the Azure AD identity.

Look at the JWT header and seeing if it contains a nonce value. These ones always seem to fail standard access token validation.

If so then using the v1 OAuth endpoints will probably fix it - though there may be alternative solutions. Worth posting a screenshot of the (sanitised) JWT contents.