Azure-docs: IDP Access Token is not a valid JWT

[xenalite]

I configured this flow and my claim "idp_access_token" starts with "AQABAAAAAAD....". This is not a valid base64 encoded JWT. Is it encrypted? If so, how do you decrypt it or exchange it for a JWT? I want to parse it as a JWT and inspect the claims.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: bfa17891-d5ec-fff3-4f9b-fbb04b2f8f03
• Version Independent ID: 0f3231f1-c01f-1439-9b6d-076af0d03e81
• Content: Pass an access token through a user flow to your application - Azure Active Directory B2C
• Content Source: articles/active-directory-b2c/idp-pass-through-user-flow.md
• Service: active-directory
• Sub-service: b2c
• GitHub Login: @davidmu1
• Microsoft Alias: davidmu

[shashishailaj]

@xenalite Thank you for your feedback . We will investigate and update this thread further.

[MohitDhingra-MSFT]

@davidmu1 Could you please have this verified with engineering and make required changed within the docs as needed ?

[davidmu1]

Unfortunately, the tokens coming from the identity providers can't be examined. They are usually just a random set of characters that only the idp knows how to map.

please-close

[adriexnet]

I am having the same issue using azure active directory as identity provider, could you help me? the tokens coming from azure identity provider should be controlled environment right?

[adriexnet]

This is my claim provider configuration

<ClaimsProvider>
      <Domain>Azure Active Directory SignIn</Domain>
      <DisplayName>Azure Active Directory</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="AAD-OAUTH">
          <DisplayName>Azure Active Directory</DisplayName>
          <Description>Login with your Azure Active Directory account</Description>
          <Protocol Name="OpenIdConnect" />
          <OutputTokenFormat>JWT</OutputTokenFormat>
          <Metadata>
            <Item Key="client_id">CLIENT_ID</Item>
            <Item Key="UsePolicyInRedirectUri">false</Item>
            <Item Key="METADATA">https://login.microsoftonline.com/common/.well-known/openid-configuration</Item>
            <Item Key="response_types">code</Item>
            <Item Key="scope">openid profile</Item>
            <Item Key="response_mode">form_post</Item>
            <Item Key="HttpBinding">POST</Item>
            <Item Key="DiscoverMetadataByTokenIssuer">true</Item>
            <Item Key="ValidTokenIssuerPrefixes">PREFIX_1,PREFIX_2</Item>
          </Metadata>
          <CryptographicKeys>
            <Key Id="client_secret" StorageReferenceId="B2C_1A_AppSecret" />
          </CryptographicKeys>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="oid" />
            <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
            <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
            <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="family_name" />
            <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="unique_name" />
            <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" />
            <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
            <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="AAD-App" AlwaysUseDefaultValue="true" />
            <OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" />
          </OutputClaims>
          <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
            <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
            <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
            <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
          </OutputClaimsTransformations>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>

[b3nt0]

I've seen this as well. When using custom policy configuration similar to @adriexnet I get an access token that isn't a valid JWT.

When I use a userflow configured to return the idp access token it is correctly formatted. The user flow uses an OpenID Connect identity provider configured with my dev Azure AD tenant.

This configuration sends a JWT:
https://docs.microsoft.com/en-us/azure/active-directory-b2c/idp-pass-through-user-flow

This configuration doesn't send a valid JWT:
https://docs.microsoft.com/en-us/azure/active-directory-b2c/idp-pass-through-custom

[JasonBodley]

I've seen this as well. When using custom policy configuration similar to @adriexnet I get an access token that isn't a valid JWT.

When I use a userflow configured to return the idp access token it is correctly formatted. The user flow uses an OpenID Connect identity provider configured with my dev Azure AD tenant.

This configuration sends a JWT:
https://docs.microsoft.com/en-us/azure/active-directory-b2c/idp-pass-through-user-flow

This configuration doesn't send a valid JWT:
https://docs.microsoft.com/en-us/azure/active-directory-b2c/idp-pass-through-custom

Same here, I want to be able to pass through the JWT bearer token from my Azure AD login so that i can use it to call the Graph API. Following the user flows it returns a proper JWT token, however via custom policy (can't get away from using this) it returns some unknown compact token format which isn't of any use ... I've gone to the extent of looking at the base xml policy that is produced for the user flows and can't see what's different. My only thought is that some of the custom stuff is interfering but no idea where to start looking.

Any ideas?

[MaWa19]

Unfortunately, the tokens coming from the identity providers can't be examined. They are usually just a random set of characters that only the idp knows how to map.

please-close

Then what's the point of passing that access_token anyway?

Even the build-in flow (SignUpSignInv2) is now returning some random string for claim "idp_access_token". In my use-case Azure AD ist the IDP behind B2C and I need to get the user's initial (Azure AD) objectId. Any suggestions how to achieve this?

[Akash-JS]

Unfortunately, the tokens coming from the identity providers can't be examined. They are usually just a random set of characters that only the idp knows how to map.

please-close

Then what's the point of passing that access_token anyway?

Even the build-in flow (SignUpSignInv2) is now returning some random string for claim "idp_access_token". In my use-case Azure AD ist the IDP behind B2C and I need to get the user's initial (Azure AD) objectId. Any suggestions how to achieve this?

@MaWa19 , please check your identity provider configuration (OpenId Provider), If your metaurl in configuration doesn't contain "v2.0" it will not return proper jwt.

Your metaurl should be

https://login.microsoftonline.com/tenant-name.onmicrosoft.com/v2.0/.well-known/openid-configuration

Please replace "tenant-name" with your tenant.

[ctianls]

Thank you Akash-JS for the hint! I tried to add an AAD as an identity provider to my AADB2C using the docs:

https://docs.microsoft.com/de-de/azure/active-directory-b2c/tutorial-add-identity-providers

This worked, however the idp_access_token-claim was not usable (as described above).

As you suggested, i added the v2.0 to the metadata-url (in b2c's ip configuration). However this led to the following error message "A claim with id 'UserId' was not found, which is required by ClaimsTransformation 'CreateAlternativeSecurityId'".
After adding "profile" to the scope-Property (setting scope = "openid profile" in b2c's ip configuration) the login worked - and idp_access_token was a readable jwt.

[Akash-JS]

Thank you Akash-JS for the hint! I tried to add an AAD as an identity provider to my AADB2C using the docs:

https://docs.microsoft.com/de-de/azure/active-directory-b2c/tutorial-add-identity-providers

This worked, however the idp_access_token-claim was not usable (as described above).

As you suggested, i added the v2.0 to the metadata-url (in b2c's ip configuration). However this led to the following error message "A claim with id 'UserId' was not found, which is required by ClaimsTransformation 'CreateAlternativeSecurityId'".
After adding "profile" to the scope-Property (setting scope = "openid profile" in b2c's ip configuration) the login worked - and idp_access_token was a readable jwt.

Yeah, I should had mention "profile" related change as well in that comment.