Azure AD token absent in link API response

stefan 0

We are using Azure AD as an external identity provider via the OIDC integration, which works great and users are authenticated as expected, happy days.

We have recently however had a customer request that would require us to retrieve the access token returned from Azure AD for further processing. We can see from the debug logs that the access token is returned from Azure AD, but using the Retrieve a Link API yields an empty token property in the response in all instances. While the API documentation does say that the token may not be available in all cases, other documentation specifically for the Azure AD OIDC integration details a token storage step in the authentication flow. Have we misinterpreted the documentation here or should the token be available?

mark.robustelli

@stefan-0 Are you getting the user-id from the Retrieve a Link api call? That can me if you are making the API call successfully. I may be missing something, but I think the Retrieve a Link returns information about the Identity Provider. I don't think that will get you the token. Am I missing something? You may want to take a look at Complete an OpenID Connect Login.

stefan 0

@mark-robustelli thanks for the response, I didn't see it at the time hence the rather slow reply. I was using the version of Retrieve a Link that takes IDP id and FusionAuth user ID. The response to that call contains non-null non-empty values for all the following properties nested within an array of identityProviderLink instances:

displayName
identityProviderId
identityProviderName
identityProviderType
identityProviderUserId
insertInstant
lastLoginInstant
tenantId
userId

The only field returned with a consistently blank string value is identityProviderLink.token. This is documented as containing the "The token returned from the identity provider". I guess that could mean any of a number of tokens, but I assumed it to mean the access token response?

Debug logs show an AAD Access Token Response structure that contains populated values for access_token and id_token.

We are using themed versions of the FusionAuth login pages, though we're also using idp hints on the login URL to bypass the login forms in the instance where a user is authenticated by a 3rd party IDP.

kvi68507

@stefan-0 said in Azure AD token absent in link API response:

We are using Azure AD as an external identity provider via the OIDC integration, which works great and users are authenticated as expected, happy days.

We have recently however had a customer request that would require us to retrieve the access token returned from Azure AD for further processing. We can see from the debug logs that the access token is returned from Azure AD, but using the Retrieve a Link API yields an empty token property in the response in all instances. While the API documentation does say that the token may not be available in all cases, other documentation specifically for the Azure AD OIDC integration details a token storage step in the authentication flow. Have we misinterpreted the documentation here or should the token be available?

@stefan-0 said in Azure AD token absent in link API response:

We are using Azure AD as an external identity provider via the OIDC integration, which works great and users are authenticated as expected, happy days.

We have recently however had a customer request that would require us to retrieve the access token returned from Azure AD for further processing. We can see from the debug logs that the access token is returned from Azure AD, but using the io games
API yields an empty token property in the response in all instances. While the API documentation does say that the token may not be available in all cases, other documentation specifically for the Azure AD OIDC integration details a token storage step in the authentication flow. Have we misinterpreted the documentation here or should the token be available?

Since you mentioned that the debug logs show the token is returned, verify the exact point at which the token is being processed. This can help identify if it’s being lost or not stored correctly.

stefan 0

@kvi68507 Thanks for the reply, and Happy New Year, I'm back from vacation and looking at this again.

There is no mention in those debug logs of anything being stored, nor specifically of a token being processed, though the values are logged-out. Below is one such log entry, with sensitive information changed/obfuscated.

OpenID Connect IdP Response Debug Log for [AAD [Customer]] [8a3c7f38-472e-4123-9535-1ce307e62892]

1/6/2025 12:33:47 PM Z Call the configured Token endpoint [https://login.microsoftonline.com/289b660e-0782-4c53-9c0b-842e7a78127b/oauth2/v2.0/token]
1/6/2025 12:33:47 PM Z Endpoint returned status code [200]
1/6/2025 12:33:47 PM Z Access Token Response:
{
  "token_type" : "Bearer",
  "scope" : "email openid profile GroupMember.Read.All User.Read",
  "expires_in" : 4370,
  "ext_expires_in" : 4370,
  "access_token" : "XYZ",
  "id_token" : "ABC"
}
1/6/2025 12:33:47 PM Z Call the configured Userinfo endpoint [https://graph.microsoft.com/oidc/userinfo]
1/6/2025 12:33:47 PM Z Endpoint returned status code [200]
1/6/2025 12:33:47 PM Z Build a new user object from the returned Userinfo response:
{
  "sub" : "nUg...vTE",
  "name" : "John, Smith
  "family_name" : "Smith",
  "given_name" : "John",
  "picture" : "https://graph.microsoft.com/v1.0/me/photo/$value",
  "email" : "john.smith@example.com"
}
1/6/2025 12:33:47 PM Z Linking strategy [LinkByEmailForExistingUser]
1/6/2025 12:33:47 PM Z Resolved email to [john.smith@example.com]
1/6/2025 12:33:47 PM Z Resolved username to [null]
1/6/2025 12:33:47 PM Z Resolved unique Id to [nUg...vTE]
1/6/2025 12:33:47 PM Z Identity provider returned a unique Id [nUg...vTE].
1/6/2025 12:33:47 PM Z User with Id [ef92b199-78eb-4e1b-a11c-961479ac189f] is linked to this external user.
1/6/2025 12:33:47 PM Z Updating user: 
{
  "active" : true,
  "connectorId" : "8f95b8fa-dbad-4abd-a181-c1588aa789c6",
  "data" : {},
  "email" : "john.smith@example.com",
  "firstName" : "John",
  "fullName" : "John Smith",
  "id" : "ef92b199-78eb-4e1b-a11c-961479ac189f",
  "insertInstant" : 1680595126370,
  "lastLoginInstant" : 1734609341287,
  "lastName" : "Smith",
  "lastUpdateInstant" : 1734609015397,
  "memberships" : [ ],
  "passwordChangeRequired" : false,
  "passwordLastUpdateInstant" : 1680595126653,
  "preferredLanguages" : [ ],
  "registrations" : [ ],
  "tenantId" : "48a37aac-f779-4fce-82a1-f26f6406fc43",
  "twoFactor" : {
    "methods" : [ ],
    "recoveryCodes" : [ ]
  },
  "uniqueUsername" : "john.smith@example.com",
  "username" : "john.smith@example.com",
  "usernameStatus" : "ACTIVE",
  "verified" : true
}
1/6/2025 12:33:47 PM Z User is already registered for application with Id [ff737d7b-7d9a-479a-b09b-139ad8b8b813].
1/6/2025 12:33:47 PM Z User has successfully been reconciled and logged into FusionAuth.
1/6/2025 12:33:47 PM Z Authentication type: OPENID_CONNECT
1/6/2025 12:33:47 PM Z Authentication state: Authenticated

As you can see, the token and user info endpoints at Microsoft are called, but there's no specific mention of anything being stored, just the user record being updated. Are you familiar with these logs and have seen output that does mention storage activities?

Thanks
Stefan

stefan 0

Having contemplated raising a bug for this issue, I've discovered that it, or something very similar, is in fact already the subject of a GitHub Issue. The issue was raised out of this Forum Thread, which provides some avenues for further investigation. Thanks for the responses @mark-robustelli & @kvi68507