CODE_TO_TOKEN_ERROR when connecting Keycloak as OIDC Identity Provider for AWS Q Business app

Hi,
We are trying to use Keycloak as an identity provider in AWS, specifically to use it to authenticate to a Q Business application. We have successfully registered our Keycloak instance as an identity provider in AWS IAM. However, when users try to access the application, although they are correctly redirected to the Keycloak Log-in mask and their credentials and one-time-password are accepted, they are getting the following error in AWS: “Login failed. Invalid endpoint/response from identity provider. Retry logging in.” We enabled DEBUG in Keycloak logs and we are getting the following error message:

keycloak-1 | 2025-06-11 14:03:30,799 DEBUG [org.hibernate.internal.util.EntityPrinter] (executor-thread-13) org.keycloak.events.jpa.EventEntity{clientId=aws-test, realmId=MyRealm, ipAddress=xxx, id=7bf7ef01-d7f2-4490-bffc-154c685a4925, sessionId=39b2cf5f-eb43-4537-a712-64eb6789f2c6, time=1749650610797, error=invalid_code, type=CODE_TO_TOKEN_ERROR, userId=null, detailsJson={"grant_type":"authorization_code","code_id":"39b2cf5f-eb43-4537-a712-64eb6789f2c6","client_auth_method":"client-secret"}}

The whole relevant trace is the following:

keycloak-1 | 2025-06-11 14:03:30,796 DEBUG [org.keycloak.authentication.AuthenticationProcessor] (executor-thread-13) AUTHENTICATE CLIENT
keycloak-1 | 2025-06-11 14:03:30,796 DEBUG [org.keycloak.authentication.ClientAuthenticationFlow] (executor-thread-13) client authenticator: client-secret
keycloak-1 | 2025-06-11 14:03:30,797 DEBUG [org.keycloak.authentication.ClientAuthenticationFlow] (executor-thread-13) client authenticator SUCCESS: client-secret
keycloak-1 | 2025-06-11 14:03:30,797 DEBUG [org.keycloak.authentication.ClientAuthenticationFlow] (executor-thread-13) Client aws-test authenticated by client-secret
keycloak-1 | 2025-06-11 14:03:30,797 DEBUG [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] (executor-thread-13) getUserSessionWithPredicate(39b2cf5f-eb43-4537-a712-64eb6789f2c6): found in local cache
keycloak-1 | 2025-06-11 14:03:30,797 WARN [org.keycloak.protocol.oidc.utils.OAuth2CodeParser] (executor-thread-13) Code 'fc613b7f-1af9-409e-a018-9e59c8d5e634' already used for userSession '39b2cf5f-eb43-4537-a712-64eb6789f2c6' and client '3f038763-0c3f-4b25-84f6-9ba1d2367a9e'.
keycloak-1 | 2025-06-11 14:03:30,797 DEBUG [org.keycloak.transaction.JtaTransactionWrapper] (executor-thread-13) new JtaTransactionWrapper
keycloak-1 | 2025-06-11 14:03:30,797 DEBUG [org.keycloak.transaction.JtaTransactionWrapper] (executor-thread-13) was existing? true
keycloak-1 | 2025-06-11 14:03:30,798 DEBUG [org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl] (executor-thread-13) hibernate.connection.provider_disables_autocommit was enabled. This setting should only be enabled when you are certain that the Connections given to Hibernate by the ConnectionProvider have auto-commit disabled. Enabling this setting when the Connections do not have auto-commit disabled will lead to Hibernate executing SQL operations outside of any JDBC/SQL transaction.
keycloak-1 | 2025-06-11 14:03:30,798 DEBUG [org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl] (executor-thread-13) Hibernate RegisteredSynchronization successfully registered with JTA platform
keycloak-1 | 2025-06-11 14:03:30,798 DEBUG [org.hibernate.event.internal.AbstractSaveEventListener] (executor-thread-13) Generated identifier: 7bf7ef01-d7f2-4490-bffc-154c685a4925, using strategy: org.hibernate.id.Assigned
keycloak-1 | 2025-06-11 14:03:30,798 DEBUG [org.keycloak.transaction.JtaTransactionWrapper] (executor-thread-13) JtaTransactionWrapper commit
keycloak-1 | 2025-06-11 14:03:30,798 DEBUG [org.hibernate.event.internal.AbstractFlushingEventListener] (executor-thread-13) Processing flush-time cascades
keycloak-1 | 2025-06-11 14:03:30,798 DEBUG [org.hibernate.event.internal.AbstractFlushingEventListener] (executor-thread-13) Dirty checking collections
keycloak-1 | 2025-06-11 14:03:30,799 DEBUG [org.hibernate.event.internal.AbstractFlushingEventListener] (executor-thread-13) Flushed: 1 insertions, 0 updates, 0 deletions to 1 objects
keycloak-1 | 2025-06-11 14:03:30,799 DEBUG [org.hibernate.event.internal.AbstractFlushingEventListener] (executor-thread-13) Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
keycloak-1 | 2025-06-11 14:03:30,799 DEBUG [org.hibernate.internal.util.EntityPrinter] (executor-thread-13) Listing entities:
keycloak-1 | 2025-06-11 14:03:30,799 DEBUG [org.hibernate.internal.util.EntityPrinter] (executor-thread-13) org.keycloak.events.jpa.EventEntity{clientId=aws-test, realmId=MyRealm, ipAddress=xxx, id=7bf7ef01-d7f2-4490-bffc-154c685a4925, sessionId=39b2cf5f-eb43-4537-a712-64eb6789f2c6, time=1749650610797, error=invalid_code, type=CODE_TO_TOKEN_ERROR, userId=null, detailsJson={"grant_type":"authorization_code","code_id":"39b2cf5f-eb43-4537-a712-64eb6789f2c6","client_auth_method":"client-secret"}}

Apparently, the problem is caused by this “CODE_TO_TOKEN_ERROR”. Maybe these messages logged before the CODE_TO_TOKEN_ERROR have something to do, but we are not sure, because we deleted every active session in Keycloak before doing the test:

keycloak-1 | 2025-06-11 14:03:30,797 DEBUG [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] (executor-thread-13) getUserSessionWithPredicate(39b2cf5f-eb43-4537-a712-64eb6789f2c6): found in local cache
keycloak-1 | 2025-06-11 14:03:30,797 WARN [org.keycloak.protocol.oidc.utils.OAuth2CodeParser] (executor-thread-13) Code 'fc613b7f-1af9-409e-a018-9e59c8d5e634' already used for userSession '39b2cf5f-eb43-4537-a712-64eb6789f2c6' and client '3f038763-0c3f-4b25-84f6-9ba1d2367a9e'.

We are in touch with AWS support as well, but apparently everything is configured properly in AWS. Googling this error, we found it could be caused by an incorrect “redirect_uri”, but AWS Support confirmed the “redirect_uri” we are using in our Keycloak client is correct. So far, we haven’t been able to find proper documentation on how to integrate Keycloak as an OIDC identity provider within AWS, so apparently we are missing something on the Keycloak side. Any ideas what could it be? Does anyone have been successful in such an integration before that can give us some hints?

Thanks in advanced!

José

If someone ever faces this issue in the future, the correct configuration in Keycloak is:

  1. Go to your Client, Client Scopes and click on the dedicated client scope link, I think the name always follow the convention -dedicated.
  2. Create a new mapper “by configuration” of type “User Attribute”
  3. Relevant values are:
  4. User Attribute  = email
    Token Claim Name = https://aws\.amazon\.com/tags.principal_tags.Email
    Claim JSON Type = String
    Add to ID Token = On
    Add to Access Token = On
    Multivalued = On
    Aggregate attribute values = On
    

With that configuration, we were able to use Keycloak as an identity provider for our AWS Q Business App.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.