[keycloak-dev] Authorization code and refresh tokens in cross DC

[Marek Posolda]

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
> leaked.
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 [1] 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...

Marek
>
> 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.
>
> [1] https://tools.ietf.org/html/rfc7636
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev