Closed jfstgermain closed 6 years ago
I'm going off of memory here, so forgive me if details are off (I'll grab the reference material when time allows and share), but that's not correct.
The initial auth returns an ID token in the implicit grant (or bearer) flow. That big difference with that ID token in the bearer flow as opposed to, say, the more secure Authorization Grant Flow is essentially the absence of a secure web application capable of maintaining a client secret -- hence why the bearer flow issues ~2 hour tokens, while the authorization grant flow has tokens lasting sometimes weeks / longer with refresh tokens.
The ID token is basically the same as the auth token in any case; it just represents the credentials of a user authenticating against AAD and is very short lived "This user exists, is in control of the user's credentials, and is allowed to act as / on behalf of the user".
The ID token needs to still be used to acquire an access token for a specific resource from the token endpoint -- hence why after retrieving the ID token, the ADAL library still makes calls to the token endpoint, utilizing that ID token to acquire access tokens.
Take a look at the application storage to inspect the tokens; there will be an entry for each resource defined.
Use the "authenticationContext.acquireToken( resource, callbackFunc )" command to get an access token; for the callback:
callback ( err, token )
Grab the token from the response & that bad boy should be what you'll want to validate.
Thanks for your detailed response!! Very appreciated... That's exactly what I'm doing. When I look in the persistent storage I see that adal.access.token.key...
has the same value as the adal.idtoken
entry. That is the value being sent in the authorization header (I'm calling AuthenticationContext.acquireToken()
which returns the same value as the ID token). I tried calling acquireToken()
with either the Object ID or Client ID, same result.
You'll always want to use the Client ID. The Object ID is only used when interacting with the Microsoft Graph API to make modifications to the application object itself directly. The client ID is used for the actual auth process, and also changes its name based on the context of its use:
ClientID: when used as the client application, representing the actual app ran in a user-agent that requires auth
ResourceID: when a client application needs access to a different resource, that resource must also have a presence in Azure. In this case, that resource's client id is referred to as a resource ID representing that relationship.
In the event that you're using the same client Id for both the client and the resource, it's possible the Id token returned also acts as an access token. I do this somewhere in one of my projects, but I don't remember off the top of my head.
Hello,
I'm trying to validate the token sent by a Vue application (using this module) when calling my API (using https://github.com/AzureAD/passport-azure-ad#52-bearerstrategy) Unfortunately I always get the following error: Error: a key with the specific kid cannot be found.
From the log traces, the
kid
claim of the jwt is not part of the list ofkid
s retrieved by the aad passport strategy. I'm new to how AAD works, given that there are 3 possible types of tokens, I'm wondering if the right type of token is being sent to my API. From my understanding configuring the azure application manifest withoauth2AllowImplicitFlow: true
ensures that we're getting an access token when authenticating and not an ID token is that correct?Thanks in advance