Signed JWT - Federated #50225

keycloakuser41 · 2026-06-22T16:26:49Z

keycloakuser41
Jun 22, 2026

Am using version 26.6.1. I am testing the signed jwt- federated client authentication, with identity provider and federated subject as entra token claim “aud”. I have used the entra token as client assertion with grant type client_credentials with keycloak client id. It’s giving error invalid client. Then I renamed the “sub” claim value from entra token and renamed the client name with the “sub” value and provided sub claim value in federated subject. Now am getting the error “Token jti claim is required”

And checked in entra token which is not sending JTI claim in the token.

Am having few questions,

Entra token sub claim value is expecting is not matching with keycloak id. How to make sure keycloak client id is mapped to sub claim. Currently application uri is having keycloak realm info.
Since Entra is not having jti claim, I tried to map the uti claim from entra using idp attribute mapper the tried with client scope mapper. Still getting the “Token jti claim is required” (this error came when I renamed the sub claim value with client name and for federated subject too)

Note: I have enabled supports client assertion and Allows Client ID for audience for assertions.( Tested without Allows Client ID for assertions also).

Do we have any insight on what can we do to make signed jwt - federated working.

starkmarkus · 2026-06-22T17:01:18Z

starkmarkus
Jun 22, 2026

I think there are two separate things here.

For Signed JWT - Federated, Keycloak does not map the Entra token sub to the Keycloak client id via normal protocol mappers. The lookup is:

external issuer + external subject  ->  Keycloak confidential client

So the Keycloak client can keep its own local client id, but in the client credentials configuration you need to set:

Client Authenticator: Signed JWT - Federated
Identity provider:    <your Entra/OIDC IdP alias>
Federated Subject:    exactly the value of the `sub` claim in the Entra token

The Federated Subject is the external client id / external subject. It does not have to be the same string as the Keycloak client id, but it must match the incoming assertion’s sub.

For the audience, the assertion should normally have aud set to the Keycloak realm issuer URL, for example:

https://<keycloak-host>/realms/<realm>

or, if you enable “Allows Client ID for audience for assertions”, then Keycloak can also accept the external client id as audience. I would first try the realm issuer URL as audience if you can control the Entra token audience.

The jti problem is different. The error:

Token jti claim is required

means Keycloak is validating the incoming JWT client assertion and expects a real jti claim in that assertion. Mapping Entra’s uti to jti with identity-provider mappers or client-scope mappers will not help here, because those mappers are applied when Keycloak issues/links tokens, not before the incoming client_assertion is validated for client authentication.

So if the Entra token really has no jti, you probably have only a few options:

Configure Entra / the workload identity token source to issue a JWT that contains jti, if possible.
Use a different assertion/token type from Entra that includes jti.
Use normal private_key_jwt / self-signed client assertion instead of federated client authentication.
Open a Keycloak issue/discussion asking whether uti should be accepted as a replay-prevention identifier for Entra-issued assertions, or whether jti can be made configurable/optional for this authenticator.

I would not rename the sub claim or rename the Keycloak client to match it. The cleaner setup is to leave the Keycloak client id as your local client id and put the Entra token’s actual sub value into Federated Subject.

So my suggested checklist would be:

Decode the Entra JWT.
Confirm iss matches the configured Entra OIDC identity provider.
Confirm aud is acceptable to Keycloak.
Copy the exact sub value into the Keycloak client's Federated Subject field.
Confirm the token has exp.
Check whether the token has jti.
If it only has uti, do not try to fix that with protocol mappers; the assertion is rejected before those mappers can help.

My current guess is that your subject mapping can be fixed by setting Federated Subject to the Entra sub, but the remaining blocker is the missing jti claim in the assertion.

5 replies

keycloakuser41 Jun 22, 2026
Author

Thanks for the response.

When am using the oidc IDP( having all the required Entra config) alias with sub claim value as federated subjected is giving invalid client error unless change the client id to sub claim value. But when changed as you rightly said getting Token jti claim is required error.

I have gone through checklist. Everything is there except jti claim instead having uti claim in entra token.

is there a way to use token exchange Entra token and create a new assertion without using client secret or private key with signed jwt - federated or any other way.

starkmarkus Jun 22, 2026

I don’t think token exchange will solve this particular problem, at least not in the direct way.

The blocker is earlier in the flow: the Entra JWT is being used as the client_assertion for client authentication. Keycloak validates that assertion before it can authenticate the client. If the authenticator requires jti and the assertion only has uti, then protocol mappers, client-scope mappers, or a later token-exchange step cannot fix that incoming assertion, because it is rejected before those parts of the flow run.

So the flow you want would have to be something like:

Entra token without jti
  -> some trusted component creates a new JWT assertion with jti
  -> Keycloak token endpoint accepts that assertion

But that “some trusted component” would need signing credentials of its own, because the new assertion must be signed. Without a client secret, private key, or another trusted signer, Keycloak has no way to trust a newly created assertion.

So I think the realistic options are:

Configure Entra / workload identity to issue a token that contains jti, if possible.
Use a different Entra token/assertion type that includes jti.
Use private_key_jwt / normal signed JWT client authentication, where your client creates the assertion and includes jti.
Put a trusted broker in between that validates the Entra token and signs a new Keycloak-compatible assertion with jti.
Ask/open an issue whether the federated client authenticator can accept Entra's uti as the replay-prevention claim, or make the claim name configurable.

The broker option is possible architecturally, but it is no longer “without secret or private key”; the broker itself must hold signing credentials trusted by Keycloak.

About the “invalid client unless I change the Keycloak client id to the sub” part: that still sounds like either the federated subject lookup or the audience/client-id option is not matching exactly. But once that mapping is correct, the next error is expected to be the jti error if the Entra assertion really has no jti.

So my current conclusion is:

Token exchange will not add jti to the incoming client_assertion before client authentication.
A mapper will not help because the assertion is rejected before mapping.
A new assertion with jti requires some trusted signer.
If Entra cannot emit jti, Keycloak probably needs a feature/change to accept uti or configure the replay-id claim for this authenticator.

keycloakuser41 Jun 22, 2026
Author

Thanks a lot! Got it. It’s really helpful. I have checked Entra which is not sending the JTI claim in the token and cannot send jti claim in token.

Regarding keycloak side, want to understand is it possible to try out Entra client as assertion to keycloak client as signed jwt - federated because of jti claim limitations.

This links explains for federated. But not sure how audience is mapped to aud and sub is mapped to external idp is validated against keycloak client id.

https://www.keycloak.org/2026/01/federated-client-authentication

Appreciate any help on this.

starkmarkus Jun 22, 2026

@keycloakuser41\n\nI think this is the key point:

For the OIDC variant of Signed JWT - Federated, Keycloak is not doing a normal "claim mapper" flow.

The incoming Entra JWT is used directly as the client_assertion. Keycloak validates it first, and only if validation succeeds does it authenticate the Keycloak client.

The matching is roughly:

iss  -> must match the configured external OIDC identity provider
sub  -> must match the Federated Subject configured on the Keycloak client
aud  -> must be accepted as audience for the assertion
jti  -> must exist for replay protection
exp  -> must be valid

So aud is not mapped to the Keycloak client id in the same way a protocol mapper maps claims into a token. It is checked as the expected audience of the assertion.

For OIDC federated client authentication, the intended setup is usually:

Entra token iss  = Entra issuer
Entra token sub  = external client/workload identity
Entra token aud  = Keycloak realm issuer URL
Keycloak client Federated Subject = exact Entra sub
Keycloak client Identity Provider = Entra IdP alias

If Allows Client ID for audience for assertions is enabled, Keycloak may also accept the external client id as aud, but I would first try to make aud equal to the Keycloak realm issuer URL if Entra lets you control the audience.

However, in your case the hard blocker still seems to be jti.

If Entra cannot issue a jti claim in that token, then I do not think the normal OIDC Signed JWT - Federated flow can work with that exact Entra token, because Keycloak rejects the assertion before any mapper or token-exchange logic can modify it.

So the answer to:

is it possible to try out Entra client as assertion to Keycloak client as signed jwt - federated because of jti claim limitations?

would be: probably not with that Entra token as-is.

The realistic options are still:

Find an Entra-issued token type that includes jti.
Configure Entra/workload identity differently if there is a way to emit jti.
Use private_key_jwt, where your client creates its own assertion with jti.
Use a trusted broker that validates Entra and signs a new Keycloak-compatible assertion with jti.
Ask for a Keycloak enhancement to allow using Entra's uti as the replay identifier instead of requiring jti.

The part that confused me earlier is your "invalid client unless I change the Keycloak client id to the sub" result. If that is still happening, I would double-check the exact values of:

Entra iss
configured IdP alias selected in the Keycloak client
Entra sub
Federated Subject
Entra aud
whether Allows Client ID for audience for assertions is enabled

But even if that lookup is fixed, the next failure will still be Token jti claim is required unless the assertion contains jti or Keycloak changes to accept uti.

So my current conclusion is:

Entra -> Keycloak Signed JWT - Federated is conceptually possible only if the Entra JWT satisfies Keycloak's required assertion claims. If the available Entra token has no jti and Keycloak requires jti, then this particular direct setup is blocked.

keycloakuser41 Jun 23, 2026
Author

Appreciate your inputs. Let me check on that.

Navigation Menu

Repository navigation

Signed JWT - Federated #50225

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment 5 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Signed JWT - Federated #50225

Uh oh!

keycloakuser41 Jun 22, 2026

Replies: 1 comment · 5 replies

Uh oh!

starkmarkus Jun 22, 2026

Uh oh!

keycloakuser41 Jun 22, 2026 Author

Uh oh!

starkmarkus Jun 22, 2026

Uh oh!

keycloakuser41 Jun 22, 2026 Author

Uh oh!

starkmarkus Jun 22, 2026

Uh oh!

keycloakuser41 Jun 23, 2026 Author

keycloakuser41
Jun 22, 2026

Replies: 1 comment 5 replies

starkmarkus
Jun 22, 2026

keycloakuser41 Jun 22, 2026
Author

keycloakuser41 Jun 22, 2026
Author

keycloakuser41 Jun 23, 2026
Author