ID tokens vs Access tokens in implicit grant flow

2
votes

I would like some clarification on how to use ID tokens and access tokens in an implicit grant flow. I have an Angular SPA using MSAL.js for Angular package and a Web API. The API does NOT call any external services, like MSFT Graph. The back end uses role claims from JWT to establish RBAC authorization to our API functionality only.

This doc says: https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens

id_tokens are sent to the client application as part of an OpenID Connect flow. They can be sent along side or instead of an access token, and are used by the client to authenticate the user.

ID Tokens should be used to validate that a user is who they claim to be and get additional useful information about them - it shouldn't be used for authorization in place of an access token.

This doc shows an authentication flow where a web API is called with an ID token instead of an access token: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-implicit-grant-flow

This sample code sends ID token too (calling own Web API sample): https://github.com/Azure-Samples/active-directory-javascript-singlepageapp-dotnet-webapi-v2

The sample back end validates ID token audience against Client ID of the app that issued it.

Given our API is the only consumer of tokens, should we use ID tokens or access tokens?

2
azure-active-directorymsal.js
In the article and the sample you link to, could you point to the specific section (or quote), or file and line where the ID token is being used to call the web API? – Philippe Signoret
@PhilippeSignoret I ran the sample and inspected the token. The sample tells you to validate token audience by setting it to client ID of the app. Only ID tokens have aud claim set to client ID of the app. In the article diagram it shows passing the token to Web API after MSAL gets it from the fragment. By default MSAL will only get an ID token and send it to the backend. – oskarm
The aud claim of the access token will have the client ID of your API (i.e. the app ID of the app registration for the API). This will only be the app ID of the client when you're using the same app registration for both the frontend and backend. In all cases, the token your frontend is sending to the API is the access token, not the ID token. MSAL does not make API requests to your backend. When calling any of the acquireToken... functions, MSAL will return an access token to he used by the application's code when calling the backend. – Philippe Signoret
If you could point out which files/lines suggest what you describe, we could clarify that part. – Philippe Signoret
I'm sorry, you're completely right about the sample: it is sending an ID token to the API. (What I said about access vs. ID tokens is accurate, what I said about what the sample is doing is not accurate.) I will dig into this to understand why the sample is sending ID token (i.e. is it the sample or is it MSAL?) and report back. In any case, the general answer to your question is that clients are expected to send access tokens, not ID tokens, to the API. – Philippe Signoret

2 Answers

0
votes

Generally speaking, when securing your API with the Microsoft Identity platform, clients should be using the access token when making API requests, not the ID token.

0
votes

check this part enter image description here

It first calls acquireTokenSlient, which gets a token from the cache if available if not it calls acquireTokenPopUp which will get an acces token for the specific scope, I am not sure if it would open up a popup window or will get a token in the background with hidden iframe. But it would fetch an access token for sure. API can never be accessed with ID token.

check https://docs.microsoft.com/bs-latn-ba/azure/active-directory/develop/scenario-spa-acquire-token for more clarification