Consider the placement of gty claim in JWT minted by Client Credentials Grant

[jobannon]

Problem

Currently, we place the gty claim in the header when we generate a JWT. There may be some compatibility issues with certain services, which may expect that claim in the body.

Solution

Offer customization with where this claim can be placed.

Additional context

https://inversoft.slack.com/archives/C073KRR5Q90/p1727289281655169?thread_ts=1727285806.208769&cid=C073KRR5Q90

Azure seems to take issue with this when building this type of integration

1. Create an Azure AD app registration.
2. Add the Azure Service Management API permission with user_impersonation (Could be anything depending on what we are trying to access).
3. Configure a federated credential within the App Registration, setting the issuer to FusionAuth identity provider and the subject/audience to the FusionAuth Entity.
4. Obtain a JWT token from FusionAuth using the client_credentials flow. (see code snippet)
5. Use Azure ConfidentialClientApplication with ClientAssertion (JWT from FusionAuth) to request an access token scoped for https://management.azure.com/.default. (see code snippet)
6. Use the token returned by Microsoft to call different APIs (Service Management APIs in this case)

The following error message is generated

AADSTS5002726: Invalid JWT token. Found unsupported token header. Supported headers are: 'alg', 'typ', 'x5t', 'x5t#S256', 'x5c', 'kid', 'use', 'enc', 'ctx', 'nonce', 'rh', 'kdf_ver', 'jku', 'jwk', 'x5u'.

Of course, it is possible that this error message is related to a limitation of Azure with this service and not related to the placement of the qty header.

Seemingly, in the competitive landscape, this claim is included in the body.

• https://auth0.com/docs/secure/tokens/access-tokens/access-token-profiles

Additional notes

• a list of registered JWT header claims
• the JWS spec includes a list of registered header names: alg jku jwk kid x5u x5c x5t x5t#S256 typ cty crit
• Azure says it supports: alg typ x5t x5t#S256 x5c kid use enc ctx nonce rh kdf_ver jku jwk x5u

Per https://www.rfc-editor.org/rfc/rfc7515.html#section-4.2

However, in order to prevent collisions, any new Header Parameter
name should either be registered in the IANA "JSON Web Signature and
Encryption Header Parameters" registry established by Section 9.1 or
be a Public Name (a value that contains a Collision-Resistant Name).

New Header Parameters should be introduced sparingly, as they can
result in non-interoperable JWSs.

where Collision-Resistant Name is defined as:

A name in a namespace that enables names to be allocated in a
manner such that they are highly unlikely to collide with other
names. Examples of collision-resistant namespaces include: Domain
Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and
X.670 Recommendation series, and Universally Unique IDentifiers
(UUIDs) [RFC4122].

So it appears that the RFC 7515 guidance is that we should have either registered gty in the IANA registry or used a longer identifier that we controlled. But the recommendation isn't a requirement (a MUST. If some IdPs don't like this claim in the header, this doesn't seem to a be a collision concern, as much as it is "we don't expect to see this claim" issue.

Related links:

• Same issue in the SAP forums, unanswered: https://community.sap.com/t5/technology-q-a/forwarding-user-identity-from-sap-btp-to-azure/qaq-p/12682019
• A bug in some identity model extensions: [Bug] Breaking change in 6.18.0 due to Always set 'cty==JWT' when creating a JWE. AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet#1877

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[jdanton-believer]

We hit this issue as well with AWS. As per their OIDC identity provider docs:

Verify that the JWT header has parameter values formatted as "string." Any other data type in the JWT header results in an error.

This issue is a blocker for us using FusionAuth. Is there any current workaround?

[mooreds]

@jdanton-believer no current workaround, since the header is inaccessible to the lambda.

This would require a product change, either to allow a lambda to modify the header or product work to remove/rework the gty claim.

Thanks for letting us know this is a blocker.

[jdanton-believer]

@mooreds thank you for the quick response!

I understand that the gty header being an array isn't technically in violation of the JWT spec, but since it is non-standard, it is clearly causing issues integrating with some popular systems. I also understand that allowing lambdas to modify headers is not necessarily something you want to offer and would take time to discuss before committing to it.

Given that, do you think it reasonable to offer a config in the "JWT" section of FusionAuth to disable non-standard headers? As there is little to no upside for most use cases and clear downside?

[mooreds]

@jdanton-believer I can't really speak to possible solutions and what is "reasonable" or not.

This issue has been raised internally, but I am not sure where it stands.