9:27 a.m.
Hi Nithin,
thank you for your quick reply. Is there some automatism for deactivating and disabling
keys? As far as I know, none of our admins does this manually, but obviously in our case
some keys were disabled.
Thanks
Björn
-----Ursprüngliche Nachricht-----
Von: Chandrashekhar, Nithin [mailto:Nithin.Chandrashekhar@Teradata.com]
Gesendet: Mittwoch, 7. August 2019 08:38
An: Peemöller, Björn; 'keycloak-user(a)lists.jboss.org'
Betreff: Re: [keycloak-user] How does the public key rotation in Keycloak work?
Hi Björn,
https://www.keycloak.org/docs/latest/server_admin/index.html#rotating-keys - Here is the
documentation for rotating keys.
Keys can be in three states active, passive and disabled.
- Key in active state with the highest priority will be used for signing and validating
jwt token.
- If the key is passive, it will be used for validating the already issued jwt token.
- If the key is disabled or deleted, jwt tokens signed with these keys will be
invalidated.
Thanks
Nithin
On 8/6/19, 11:19 PM, "keycloak-user-bounces(a)lists.jboss.org on behalf of Peemöller,
Björn" <keycloak-user-bounces(a)lists.jboss.org on behalf of
Bjoern.Peemoeller(a)berenberg.de> wrote:
[External Email]
________________________________
Hi all,
I have some questions regarding the public key rotation in Keycloak.
We have an Spring Boot 2.1 application providing a rest api that is secured by
Keycloak, and we occasionally get requests that are rejected with a 401 Unauthorized and
the following information in the log:
Failed to verify tokenorg.keycloak.exceptions.TokenNotActiveException: Token is not
active
at org.keycloak.TokenVerifier$2.test(TokenVerifier.java:84)
at org.keycloak.TokenVerifier.verify(TokenVerifier.java:370)
at org.keycloak.RSATokenVerifier.verify(RSATokenVerifier.java:89)
at
org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(AdapterRSATokenVerifier.java:56)
at
org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(AdapterRSATokenVerifier.java:37)
at
org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:99)
at
org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:84)
at
org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:68)
at
org.keycloak.adapters.springsecurity.filter.KeycloakAuthenticationProcessingFilter.attemptAuthentication(KeycloakAuthenticationProcessingFilter.java:147)
...
Didn't find publicKey for kid: <some kid>
Failed to verify tokenorg.keycloak.common.VerificationException: Didn't find
publicKey for specified kid
at
org.keycloak.adapters.rotation.AdapterRSATokenVerifier.getPublicKey(AdapterRSATokenVerifier.java:47)
at
org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(AdapterRSATokenVerifier.java:55)
at
org.keycloak.adapters.rotation.AdapterRSATokenVerifier.verifyToken(AdapterRSATokenVerifier.java:37)
at
org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticateToken(BearerTokenRequestAuthenticator.java:99)
at
org.keycloak.adapters.BearerTokenRequestAuthenticator.authenticate(BearerTokenRequestAuthenticator.java:84)
at
org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:68)
at
org.keycloak.adapters.springsecurity.filter.KeycloakAuthenticationProcessingFilter.attemptAuthentication(KeycloakAuthenticationProcessingFilter.java:147)
...
We tuned our logging to have a look at the provided Bearer token, and discovered that
the rejected call performed at 2019-08-07T03:00:00Z used a token which was issued at
2019-08-05T03:00:00Z and expired at 2019-08-05T11:00:00Z. Thus, the call was performed
using an expired token. However, the above stack trace did not directly lead us into this
direction.
Obviously, the token is checked whether its active (leading to the first two errors)
and its kid is verified (leading the third error).
My guess is that the provided token is so old that the kid has already been removed
from the Keycloak server. Could anybody explain to me how the key rotation is implemented
in Keycloak? Is there a fixed interval? Are older keys kept for a while?
Another question: I would expect dealing with invalid tokens to be regular business
for the Keycloak client adapters, therefore I don't understand why an expired token
leads to three error log entries with two stack traces. Is there a reason for this
behavior I'm not aware of? Can this be configured using log settings? Personally, I
rather would have expected warning level entries with a stack trace.
Regards,
Björn
Bei Berenberg hat der Schutz Ihrer Daten seit jeher höchste Priorität. Informationen
zum Umgang mit personenbezogenen Daten finden Sie hier:
https://www.berenberg.de/files/Rechtliche%20Hinweise/DSGVO/DSGVO-Kundenin...
Diese Nachricht einschliesslich etwa beigefuegter Anhaenge ist vertraulich und kann
dem Bank- und Datengeheimnis unterliegen oder sonst rechtlich geschuetzte Daten und
Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese Nachricht
irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender über die
Antwortfunktion. Anschliessend moechten Sie bitte diese Nachricht einschliesslich etwa
beigefuegter Anhaenge unverzueglich vollstaendig loeschen. Das unerlaubte Kopieren oder
Speichern dieser Nachricht und/oder der ihr etwa beigefuegten Anhaenge sowie die unbefugte
Weitergabe der darin enthaltenen Daten und Informationen sind nicht gestattet. Wir weisen
darauf hin, dass rechtsverbindliche Erklaerungen namens unseres Hauses grundsaetzlich der
Unterschriften zweier ausreichend bevollmaechtigter Vertreter unseres Hauses beduerfen.
Wir verschicken daher keine rechtsverbindlichen Erklaerungen per E-Mail an Dritte.
Demgemaess nehmen wir per E-Mail auch keine rechtsverbindlichen Erklaerungen oder
Auftraege von Dritten entgegen.
Sollten Sie Schwierigkeiten beim Oeffnen dieser E-Mail haben, wenden Sie sich bitte an
den Absender oder an info(a)berenberg.de. Unsere Hinweise zum Schutz personenbezogener Daten
finden Sie unter
https://www.berenberg.de/files/Rechtliche+Hinweise/DSGVO/DSGVO-Kundeninfo....
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
Bei Berenberg hat der Schutz Ihrer Daten seit jeher höchste Priorität. Informationen zum
Umgang mit personenbezogenen Daten finden Sie hier:
https://www.berenberg.de/files/Rechtliche%20Hinweise/DSGVO/DSGVO-Kundenin...
Diese Nachricht einschliesslich etwa beigefuegter Anhaenge ist vertraulich und kann dem
Bank- und Datengeheimnis unterliegen oder sonst rechtlich geschuetzte Daten und
Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese Nachricht
irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender über die
Antwortfunktion. Anschliessend moechten Sie bitte diese Nachricht einschliesslich etwa
beigefuegter Anhaenge unverzueglich vollstaendig loeschen. Das unerlaubte Kopieren oder
Speichern dieser Nachricht und/oder der ihr etwa beigefuegten Anhaenge sowie die unbefugte
Weitergabe der darin enthaltenen Daten und Informationen sind nicht gestattet. Wir weisen
darauf hin, dass rechtsverbindliche Erklaerungen namens unseres Hauses grundsaetzlich der
Unterschriften zweier ausreichend bevollmaechtigter Vertreter unseres Hauses beduerfen.
Wir verschicken daher keine rechtsverbindlichen Erklaerungen per E-Mail an Dritte.
Demgemaess nehmen wir per E-Mail auch keine rechtsverbindlichen Erklaerungen oder
Auftraege von Dritten entgegen.
Sollten Sie Schwierigkeiten beim Oeffnen dieser E-Mail haben, wenden Sie sich bitte an den
Absender oder an info(a)berenberg.de. Unsere Hinweise zum Schutz personenbezogener Daten
finden Sie unter
https://www.berenberg.de/files/Rechtliche+Hinweise/DSGVO/DSGVO-Kundeninfo....