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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev