[keycloak-dev] Authorization code and refresh tokens in cross DC
mposolda at redhat.com
Wed Mar 22 05:49:44 EDT 2017
On 22/03/17 08:49, Stian Thorgersen wrote:
> One problem with authorization codes and refresh tokens in cross DC setups
> is the fact that they are supposed to be one-time only.
> We could have an option on a realm to set if they are one-time or not (we
> already do for refresh tokens). If they are one-time we have a separate
> synchronously replicated cache to handle.
> Question though would it be acceptable that they are not one-time? It does
> imposed a certain risk as it wouldn't be possible to detect if they are
The OAuth2 specs requires that code MUST be one-time. It also mentions
that authorization server SHOULD revoke the previously issued tokens if
there is an attempt to use it second time. Which we do as OIDC
certification had test for both these scenarios - currently we revoke
the clientSession if there is an attempt to use the code twice.
If we stop support the revoking, the OIDC test will be just "yellow"
because of "should", so we are still OIDC certified. But more usage of
same code will make us "red" due to "must".
On the other hand, refresh tokens is not required to be one-time per
specification. Code is supposed to be more vulnerable as it's in the URL
and hence can occur in browser's history.
Maybe we need 2 separate caches for both? Refresh tokens can be
asynchronous by default as it's not mandated to be single use by
default. And code should likely be synchronous by default.
> For example imagine someone somehow manages to sniff all codes sent to an
> application (say it's a public application since that doesn't require
> credentials). They can then exchange the code for tokens alongside the real
> application. As the codes are not one-time this goes undetected. If codes
> on the other hand are undetected the realm application will either be the
> only one to exchange the code, or it will notice something is not right.
> This issue may be resolved by the introduction of Proof Key for Code
> Exchange  though.
Unfortunately proof-key-for-code-exchange requires support on adapter
side. So we can't rely on it as we don't know that 3rd party OIDC/OAuth
adapter supports it.
For our own adapters, we can have an optimized solution for cross-dc
anyway. As long as both "code" and "refreshToken" is JWT, which will
contain the jvmRoute, the adapter can set the cookie with that route to
ensure loadbalancer will route it to correct node.
But the 3rd party adapters is the challenge...
> For refresh tokens sure it would be nice to be able to detect leakage, but
> one-time is fairly brittle as HTTP requests are not transactional so you
> can easily end up with loosing a response which would render the old
> refresh token useless and the new one lost.
>  https://tools.ietf.org/html/rfc7636
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
More information about the keycloak-dev