[keycloak-dev] Support for invalidation of access/refresh tokens

[Bill Burke]

We will not be supporting invalidation for the first milestone release. 
  We need to focus on getting what we currently have working and working 
well.  But...

Refresh tokens are not used for authentication.  Refresh tokens are 
*only* supposed to be transmitted to the auth-server to obtain new 
access tokens.  So, if you have a short-lived access token, invalidation 
checking can happen when the application tries to obtain a new access 
token when refreshing.  This is also a good way to update user 
permissions on the fly.

For servers that support an http session, refresh tokens will be stored 
in memory in the session, so a hacker would have to hack the server's 
memory to obtain the refresh token.

If there is a security breach, IMO, the safest approach would be to 
invalidate all tokens by setting a Not-Before setting for the realm. 
This would cause a broadcast to go out to all applications to not accept 
tokens that were issued before a certain date.  I think all this should 
be done through the admin console by an admin user.  We can add more 
complex policies down the road, but I think this would be a first good step.

Again, this work should be done post milestone 1 release and already has 
a number of JIRAs scheduled for it.

On 10/23/2013 6:26 AM, Marek Posolda wrote:
> Hi,
>
> it seems that actually there is no way to invalidate access token by
> client. For example: if client recognize that his access token has been
> stolen, he may want to logout and invalidate his access token, so that
> nobody can use it anymore to authenticate REST calls via Bearer
> authentication. Actually Bearer token authentication (like
> CatalinaBearerTokenAuthenticator) just verifies the signature of access
> token, but this verification will pass for stolen access token.
>
> It seems that for supporting this feature, we may need:
> - Store all valid access tokens (either in memory or in persistent storage)
> - REST endpoint for invalidate access token, which could be used by client
> - REST endpoint for check if access token is valid, which could be used
> by application providing REST endpoints in addition to signature
> verification
>
> It seems that this problem is maybe not so bad for access tokens as long
> as they have low expiration period, but what if attacker somehow steal
> refresh token? Is it planned to have invalidation support for refresh
> tokens?
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com