Microsoft-authentication-library-for-js: v1.0 access_token generated even though v2.0 id_token was created

[aappddeevv]

When I follow the example in the README, I'm getting a v1 access_token generated after I properly create a v2 id_token. I could not determine if this was standard behavior or not, but some jwt token validation software in passport_azure_ad may be expecting a v2 token, or at least, I was expecting a v2 access_token.

I could not determine if this is desired behavior or not.

[visualjeff]

So you provided the scope appropriate for a v2.0 token? But received a v1.0 instead?

[aappddeevv]

Yes, this seems to be a problem. I used the standard scopes. I'm not sure what would cause the access_token to be issued as 1.0 even though the id_token is v2. Same scopes are supplied and the calling pattern is like the one in the example.

• https://github.com/AzureAD/passport-azure-ad/issues/379
• https://github.com/AzureAD/passport-azure-ad/issues/396

[pkanher617]

@aappddeevv is this a problem you are now seeing in the msal-core library?

[aappddeevv]

Yes, using "msal": "^0.2.4". My scopes are user.read, mail.send. I've tried other scopes (since I need some more) but these are the basic ones.

[aappddeevv]

I also used the sample application that is provided and it to returns a v1 access_token even though the id_token is v2. I use jwt.ms to decode the jwt token and looked at the "ver" attribute.

• https://github.com/Azure-Samples/active-directory-javascript-graphapi-v2

[aappddeevv]

I can't tell if this is causing passport-azure-ad to fail or not but I'm trying to confirm that this is intended behavior. I did not see anything in the library that made me think I should get v1 back. Since I cannot set the "response_type" query parameter, I'm unable to return both an id and access token in one call. It may return a v2 correctly if I could set the response_type.

[visualjeff]

Yeah, my sample code is doing the same. v2.0 id_token and I receive a v1.0 access token.

[visualjeff]

I was using version 0.2.3 of msal so I bumped the version in my SPA to 0.2.4 and still have the same issue. v2.0 id_token and I receive a v1.0 access token.

[aldegoeij]

+1
with the v2.0 endpoint I get access_token v2 and id_token v1 (and less information in id_token than if I use the v1.0 endpoint)
this is actually using Python 3+ with authlib, so it is not specific to this library.

[visualjeff]

I need to exercise my test auth code against a B2C application.

[aappddeevv]

Well I guess that we need to assume that its a v2 id_token and v1 access_token (@aldegoeij did you swap thos?) for now then and try to manage it on the opposite endpoint.

[aashiman]

The access token version returned is based on the configuration of the resource/web API. You will need to check their documentation; this is important as otherwise you wont be able to access the API and/or the data you are trying to access.

[aappddeevv]

I'm using AD, signed up for the API that was a 2.0 endpoint via the registration process. I think you are saying that it is the endpoint's fault. Both the id and access tokens come from the same place but in one case I'm getting a 2.0 token but then it starts issuing 1.0 tokens. I think your are saying that its not the library's fault it is happening e.g. there is no 1.0/2.0 token switch or parameter being used that would cause the access token to be 1.0 even though the id_token is 2.0 when using this library.

[holwech]

Copying from here: #396 - If you haven't figured it out by now already, to get a v2.0 access token go to portal.azure.com -> Azure Active Directory -> App registrations (preview) -> Find your app registration in the list -> Manifest. In the manifest file you will find a field called accessTokenAcceptedVersion, this is by default set to null, which makes the app default to v1.0 access token, even if it is registered as a v2 app (I don't know why it works like this...). To get v2.0 access tokens, set this value to 2. The Azure documentation is super confusing about this, but it seems to do the trick...

[aappddeevv]

Wow! I'll give that a try. I did not come across that part of the docs. Hopefully that solves the issuance problem and the nodejs-passport-azure authentication problem together.

[sameerag]

@aappddeevv Please let us know if the above suggestions solves your issue. Please reopen if you need more help.

[alimpaecher]

So I'm running into the same problem. I get a version 2.0 id_token and then the access_token says it itself is a v1.0 access token. I've checked the manifest however and accessTokenAcceptedVersion has been set to 2 already.

In what I believe is a related error (though that might be a misdiagnosis), I get the following error when I try to login using a personal account.

AADSTS50020: User account '[email protected]' from identity provider 'live.com' does not exist in tenant 'xxx' and cannot access the application 'xxx'(xxx) in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.

Since my manifest has
"signInAudience": "AzureADandPersonalMicrosoftAccount"
my assumption is that the for whatever reason I'm accessing some version 1.0 of Azuare AD at some point. Which does not allow for Personal accounts to be connected. Which is causing both a v1.0 token and the error above.

Does anyone know if there are other manifest settings I should be checking. Or what else could be causing this v1.0 accesstoken and sign in error?

[cjancsar]

@sameerag Please re-open this as this is still an issue.

[sameerag]

Can you please open a new issue? Our triage engineer will be able to respond faster that way.

[anilktalla]

@cjancsar / @sameerag, Is this issue tracked somewhere? I am also facing same issue and curious if someone has a workaround.

[Budlee]

@cjancsar and @sameerag

would be intrested to hear as also facing this issue