[keycloak-user] Refresh token - should it expire?

Stian Thorgersen stian at redhat.com
Tue Jun 23 10:50:57 EDT 2015


Hi,

Refresh tokens should expire, but we will be adding offline tokens at some point which won't expire until revoked by the user or admin.

In the mean time you can set a high level for the sso expiration.

When do you need to have a proper offline token?


----- Original Message -----
> From: "Juraci Paixão Kröhling" <juraci at kroehling.de>
> To: keycloak-user at lists.jboss.org
> Sent: Tuesday, 23 June, 2015 1:50:31 PM
> Subject: [keycloak-user] Refresh token - should it expire?
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hello,
> 
> I'm building a secret store application that will sit in front of
> Hawkular and will be responsible for replacing API keys into actual
> Keycloak authentication data.
> 
> Based on the suggestions from Stian, the current code does the following
> :
> 
> - - User logs in Hawkular via Keycloak
> - - Once the user wants to create a new application key/secret, the user
> is redirected to /secret-store/tokens/create , which takes the KC
> authentication data and stores the refresh_token into the database,
> creating a new key/secret
> - - User configures an external application (like a monitoring agent in
> a server), adding this key/secret to its configuration
> - - The agent makes a call to the Hawkular backend, sending this key/secre
> t
> - - An undertow filter gets this key/secret from the request, fetches
> the refresh_token from the database, gets a bearer token from Keycloak
> based on this refresh_token and sets it to the request's context (ie:
> replacing the Authorization header)
> - - Keycloak uses this bearer token to perform what it needs to do
> - - Request reaches the Hawkular backend
> 
> It all works, but the session from the *user* (second step) eventually
> expires, causing the refresh_token to be invalid[1].
> 
> So, the question is whether this token is indeed supposed to be
> attached to an user session, or if it's a bug. If the behavior I'm
> seeing is the correct one, what could be a proper way to store a token
> so that it can be replaced at a later time?
> 
> 1 - http://git.io/vLAtF
> 
> Best,
> Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJViUgHAAoJEDnJtskdmzLMCIsH/iOeGmCDANgjvliyeKMWcx0/
> j0cFdJuENBqzgPRlj0tSSJeFZeNnIs07ARJk2E0Xoq1D2gSq3KAw3hTOq7nPNfOk
> SoG5f1dLDkwCB8a+d/IGNfPw6Tmbzn0i2kwRSbhSJdfYCDxg9xiMPnV2MjvunPYa
> f6sXHz0yZjwylis3UuBw7WUNr1wAYOpjfmdBmt0B6hEqBXbIZflX2OEhim7dC+PQ
> WBx4lobqWWR+pMF12oabngNPLoE1r8SGSJkkiusMZxaTIWOViiHIYkRzVcul32z7
> 1OI0EOHnnv4YJ1rzc9frAIu7EPZq0i4BM1YT9pRBlNFBWH/ZQawEyCN6KCrNHDI=
> =EA+F
> -----END PGP SIGNATURE-----
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 



More information about the keycloak-user mailing list