Allowing Independent iss and sub Claims in JWT Authentication Across Keycloak Realms #32626

eminwux · 2024-09-03T20:22:35Z

eminwux
Sep 3, 2024

Hi Keycloak community,

I’ve encountered a problem while trying to authenticate between different Keycloak realms, and I’m hoping to initiate a discussion around it.

Here’s the situation: When I authenticate on realm tenant, I receive an ID token that looks like this:

{
    "acr": "1",
    "at_hash": "Mn1M3ZigbMmZqPuPSf6k8A",
    "aud": "confidential",
    "auth_time": 0,
    "azp": "confidential",
    "clientAddress": "172.16.1.20",
    "clientHost": "172.16.1.20",
    "client_id": "confidential",
    "email_verified": false,
    "exp": 1725393297,
    "iat": 1725392997,
    "iss": "https://core1.domain/realms/tenant",
    "jti": "8be09fbf-387d-4916-bc23-69156a9fa5cf",
    "preferred_username": "service-account-confidential",
    "sub": "0db5d38c-e8cb-46cc-98f7-919c9ea04753",
    "typ": "ID"
}

As you can see, the sub (subject) and iss (issuer) claims are different.

The issue arises when I try to use this ID token on another client in a different realm (configured with Signed JWT).

I get the following error The issuer should match the subject:

2024-09-03 15:53:03,442 WARN  [org.keycloak.events] (executor-thread-10) type=CLIENT_LOGIN_ERROR, realmId=38800375-72af-49cf-a9c1-f033d107382b, clientId=cross, userId=null, ipAddress=172.16.1.20, error=invalid_client_credentials, grant_type=client_credentials
2024-09-03 15:57:53,042 ERROR [org.keycloak.services] (executor-thread-10) KC-SERVICES0025: Error when validating client assertion: java.lang.RuntimeException: Issuer mismatch. The issuer should match the subject
	at org.keycloak.authentication.authenticators.client.JWTClientValidator.validateClient(JWTClientValidator.java:115)
	at org.keycloak.authentication.authenticators.client.JWTClientAuthenticator.authenticateClient(JWTClientAuthenticator.java:75)
	at org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:72)
	at org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:894)
	at org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:50)
	at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:253)
	at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.processGrantRequest(TokenEndpoint.java:201)
	at org.keycloak.protocol.oidc.endpoints.TokenEndpoint$quarkusrestinvoker$processGrantRequest_6408e15340992839b66447750c221d9aaa837bd7.invoke(Unknown Source)
	at org.jboss.resteasy.reactive.server.handlers.InvocationHandler.handle(InvocationHandler.java:29)
	at io.quarkus.resteasy.reactive.server.runtime.QuarkusResteasyReactiveRequestContext.invokeHandler(QuarkusResteasyReactiveRequestContext.java:141)
	at org.jboss.resteasy.reactive.common.core.AbstractResteasyReactiveContext.run(AbstractResteasyReactiveContext.java:145)
	at io.quarkus.vertx.core.runtime.VertxCoreRecorder$14.runWith(VertxCoreRecorder.java:576)
	at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1538)
	at org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:29)
	at org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:29)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:840)

I noticed that there has been a similar discussion in closed issue #15688 , where some contributors pointed out that while the spec does not explicitly require the iss and sub claims to be identical, Keycloak's current implementation enforces this requirement (see RFC 7523, Section 3). This has been problematic for others as well, especially in scenarios where JWT tokens issued by third-party STS or across different realms in Keycloak need to be validated.

There was a suggestion made by @pedroigor that this might be more of a feature request than a bug, given that allowing independent iss and sub claims would require "mechanisms to trust only the values set in the trust claim". However, the current implementation goes beyond what the spec requires, which has caused issues in real-world scenarios, like the one I’m facing. I believe revisiting this issue and allowing for more flexibility in JWT client authentication would be beneficial for many users who need to integrate Keycloak with various identity providers or multi-realm environments.

These are the code lines that are currently dictating this behavior:

https://github.com/pedroigor/keycloak/blob/2e8b1f191514559095b992440d18b12230ecab28/services/src/main/java/org/keycloak/authentication/authenticators/client/JWTClientAuthenticator.java#L108-L110

https://github.com/pedroigor/keycloak/blob/2e8b1f191514559095b992440d18b12230ecab28/services/src/main/java/org/keycloak/authentication/authenticators/client/JWTClientSecretAuthenticator.java#L101-L103

Looking forward to hearing your thoughts and any potential solutions!

Thanks,
Emiliano

gawsoftpl · 2025-03-23T17:43:29Z

gawsoftpl
Mar 23, 2025

Hi Keycloak community,

I’ve encountered a problem while trying to authenticate between different Keycloak realms, and I’m hoping to initiate a discussion around it.

Here’s the situation: When I authenticate on realm tenant, I receive an ID token that looks like this:
{
    "acr": "1",
    "at_hash": "Mn1M3ZigbMmZqPuPSf6k8A",
    "aud": "confidential",
    "auth_time": 0,
    "azp": "confidential",
    "clientAddress": "172.16.1.20",
    "clientHost": "172.16.1.20",
    "client_id": "confidential",
    "email_verified": false,
    "exp": 1725393297,
    "iat": 1725392997,
    "iss": "https://core1.domain/realms/tenant",
    "jti": "8be09fbf-387d-4916-bc23-69156a9fa5cf",
    "preferred_username": "service-account-confidential",
    "sub": "0db5d38c-e8cb-46cc-98f7-919c9ea04753",
    "typ": "ID"
}
As you can see, the sub (subject) and iss (issuer) claims are different.

The issue arises when I try to use this ID token on another client in a different realm (configured with Signed JWT).

I get the following error The issuer should match the subject:
2024-09-03 15:53:03,442 WARN  [org.keycloak.events] (executor-thread-10) type=CLIENT_LOGIN_ERROR, realmId=38800375-72af-49cf-a9c1-f033d107382b, clientId=cross, userId=null, ipAddress=172.16.1.20, error=invalid_client_credentials, grant_type=client_credentials
2024-09-03 15:57:53,042 ERROR [org.keycloak.services] (executor-thread-10) KC-SERVICES0025: Error when validating client assertion: java.lang.RuntimeException: Issuer mismatch. The issuer should match the subject
	at org.keycloak.authentication.authenticators.client.JWTClientValidator.validateClient(JWTClientValidator.java:115)
	at org.keycloak.authentication.authenticators.client.JWTClientAuthenticator.authenticateClient(JWTClientAuthenticator.java:75)
	at org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:72)
	at org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:894)
	at org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:50)
	at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:253)
	at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.processGrantRequest(TokenEndpoint.java:201)
	at org.keycloak.protocol.oidc.endpoints.TokenEndpoint$quarkusrestinvoker$processGrantRequest_6408e15340992839b66447750c221d9aaa837bd7.invoke(Unknown Source)
	at org.jboss.resteasy.reactive.server.handlers.InvocationHandler.handle(InvocationHandler.java:29)
	at io.quarkus.resteasy.reactive.server.runtime.QuarkusResteasyReactiveRequestContext.invokeHandler(QuarkusResteasyReactiveRequestContext.java:141)
	at org.jboss.resteasy.reactive.common.core.AbstractResteasyReactiveContext.run(AbstractResteasyReactiveContext.java:145)
	at io.quarkus.vertx.core.runtime.VertxCoreRecorder$14.runWith(VertxCoreRecorder.java:576)
	at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1538)
	at org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:29)
	at org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:29)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:840)
I noticed that there has been a similar discussion in closed issue #15688 , where some contributors pointed out that while the spec does not explicitly require the iss and sub claims to be identical, Keycloak's current implementation enforces this requirement (see RFC 7523, Section 3). This has been problematic for others as well, especially in scenarios where JWT tokens issued by third-party STS or across different realms in Keycloak need to be validated.

There was a suggestion made by @pedroigor that this might be more of a feature request than a bug, given that allowing independent iss and sub claims would require "mechanisms to trust only the values set in the trust claim". However, the current implementation goes beyond what the spec requires, which has caused issues in real-world scenarios, like the one I’m facing. I believe revisiting this issue and allowing for more flexibility in JWT client authentication would be beneficial for many users who need to integrate Keycloak with various identity providers or multi-realm environments.

These are the code lines that are currently dictating this behavior:

https://github.com/pedroigor/keycloak/blob/2e8b1f191514559095b992440d18b12230ecab28/services/src/main/java/org/keycloak/authentication/authenticators/client/JWTClientAuthenticator.java#L108-L110

https://github.com/pedroigor/keycloak/blob/2e8b1f191514559095b992440d18b12230ecab28/services/src/main/java/org/keycloak/authentication/authenticators/client/JWTClientSecretAuthenticator.java#L101-L103

Looking forward to hearing your thoughts and any potential solutions!

Thanks, Emiliano

Hi @eminwux , @yanxch have you find resolution for this issue, I trying to set jwks as client to keycloak but my service generate sub and iss:

{
 "iss": "https://gitlab.example.com",
  "sub": "project_path:company/project:ref_type:branch:ref:main",
 }

In gitlab I cant change that values, but keycloak required that sub == iss, I dont know how to resolve it.

0 replies

kfox1111 · 2025-05-02T16:48:15Z

kfox1111
May 2, 2025

This affects using lots of valid/different IDP's. This really feels like a bug, but if its just an enhancement, thats fine.

Is there anything blocking a fix or is it just finding a developer with time?

0 replies

yerald-mora · 2025-09-10T22:17:15Z

yerald-mora
Sep 10, 2025

i'm facing the same issue, not exactly with this library, but i'm trying to understand the specs, since rfc7523 is not that clear about the jwt identity, i would like to share the following questions and maybe check if the idea of being issuer and verifier aligns with the specification

Are authorization tokens the same than authentication tokens?
An identity server supposed to generates an authorization token (the client gets authenticated and receives a token that determine which resources the client is able to access), so does it make sense to use an authorization token generated by my identity server for client authentication?
Lastly, these 2 links
- https://oauth.net/private-key-jwt/ => referring to rfc7523 says that the token should be signed by the client's private key, so does this confirm that the client should be the issuer and not the identity server?
- https://openid.net/specs/openid-connect-core-1_0-final.html => 9. Client Authentication regarding iss "REQUIRED. Issuer. This MUST contain the client_id of the OAuth Client."

Any thoughts?

0 replies

Navigation Menu

Repository navigation

Allowing Independent iss and sub Claims in JWT Authentication Across Keycloak Realms #32626

Uh oh!

{{title}}

Uh oh!

Replies: 3 comments

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Allowing Independent iss and sub Claims in JWT Authentication Across Keycloak Realms #32626

Uh oh!

eminwux Sep 3, 2024

Replies: 3 comments

Uh oh!

Uh oh!

gawsoftpl Mar 23, 2025

Uh oh!

kfox1111 May 2, 2025

Uh oh!

yerald-mora Sep 10, 2025

eminwux
Sep 3, 2024

gawsoftpl
Mar 23, 2025

kfox1111
May 2, 2025

yerald-mora
Sep 10, 2025