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

[Marek Posolda]

On 23.10.2013 14:51, Bill Burke wrote:
> 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.
Yeah, this would be good option, however it invalidates all tokens and 
not just one particular token. If some user reports to admin that his 
access/refresh token has been stolen, admin probably doesn't want to 
update Not-Before for whole realm as it will affect all other existing 
tokens of other users. So IMO endpoint for invalidation of single 
refresh token will be probably needed as well.

Marek
>
> 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
>>