7:51 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com