2

I have a JWT coming from Azure after authenticating myself via login.microsoftonline.com, that has the iss value of https://sts.windows.net/... (after doing some research, it seems this is due to the "ver": 1.0 of the JWT). In order to get a JWT issued by https://login.microsoftonline.com/... I have updated the app's Manifest, so that the accessTokenAcceptedVersion is set to 2, and not null as per default anymore.

I waited more than 5 hours, but I still get the wrong version of the token, I keep getting the JWT with "ver": 1.0 and "iss": "https://sts.windows.net/...". Is there any step that I am missing?

The scope of the AuthConfig has the value openid and I'm currently using Implicit Flow (will change to auth code flow soon, but only after the JWT version issue is fixed..)

Thanks in advance!

Vincentius Daniel
  • 138
  • 1
  • 9

1 Answers1

0

The version of the access token has nothing to do with the endpoint you use to request the token, but is related to the resource you requested. The default version of ms graph api is the token of version 1.0. If you want to obtain the 2.0 version of the token, you should request your custom api.

First, you need to create an application that represents the api, and then expose the api protected by Azure.

enter image description here

Next,under 'API permissions', give your front-end application access to your backend api:

  • Under 'API permissions' click on 'Add permission', then click on the 'My APIs' tab.
  • Find your backend application and select the appropriate scope.
  • Click 'Add permissions'.
  • Grant admin consent for your APIs.

enter image description here

Next, you need to use the auth code flow to obtain an access token,which requires you to log in to the user and obtain the authorization code, and then use the authorization code to redeem the access token.

enter image description here

Parse the access token, it will show v2.

enter image description here

Carl Zhao
  • 8,543
  • 2
  • 11
  • 19
  • I do not have direct access to change anything in Azure, unfortunately, but your answer has given me an idea to put the existing scope that I already have in the AuthConfig `scope`. But this scope that already exists in the first place sounds like `https:///user_impersonation` (does not start with api://) and has "Admins and users" as "Who can consent"; is such practice recommended? Adding this scope indeed gives me the correct `iss` and `ver`, though :) – Vincentius Daniel Jan 21 '21 at 10:23
  • I recommend your approach. The api you add is actually a custom api protected by Azure. Custom api is not mandatory to start with `api://`, it can be customized, just like you added. – Carl Zhao Jan 22 '21 at 09:56