I am currently facing an issue with a custom mapper that extends AbstractOIDCProtocolMapper and implements OIDCAccessTokenMapper in Keycloak version 23. This mapper overrides the “iss” value returned in the access_token with a configurable value and was working perfectly fine in Keycloak version 21.1.1.
However, in Keycloak 23, when the application requests a new access token using the refresh token containing the custom “iss” claim, I receive the following error: “{“error”:“invalid_grant”,“error_description”:“Invalid token issuer. Expected $REALM_URL”}”.
Is it possible to prevent this error from occurring during the retrieval of a new token? Alternatively, is it possible to ensure that the refresh_token does not contain the modified “iss” claim applied by the custom mapper?
I would appreciate any guidance or advice that you can provide regarding this matter.
From the chapter “not everything what’s technically possible, might be a good idea…”
Overriding the issuer in a token mapper is a very bad practice, as the receiver of the token is not able to verify it against the issuer in the .well-known/openid-configuration document, but this required by the spec.
Expect this was a failure/bug in former KC versions, don’t rely on “but it worked formerly…”.
I just blogged about adjusting the issuer globally in Keycloak, which is natively not supported, but I had this requirement and I looked for a way to change it in the root, so that it is always and everywhere being used, in tokens, in the openid-configuration document, …
Yes, my heart did break a little when I had to develop that specific mapper, but unfortunately, in very specific cases, there is no choice but to do some dirty code…
I suspected that this “dirty hack” would eventually become problematic. That was bound to happen. Anyway, we could talk about it for hours!
I will carefully review the blog and see if it can address my issue. Once again, thank you for your response !
I resolved my issue by creating a new Mapper that implements OIDCAccessTokenResponseMapper and overriding the issuer of the refresh token with the expected URL.
I added this mapper to the client and it seems to be good enough for my use case.
Ultimately, I have a mapper that changes the issuer in the access token and another mapper that forces the issuer in the refresh token to the default value…
