[keycloak-dev] Authorization code and refresh tokens in cross DC
bburke at redhat.com
Wed Mar 22 10:16:49 EDT 2017
I know I suggested this as a possible solutionn, but I was thinking
about this more last night. Optimizations of session replications have
the following limitations each requiring additional data be available in
the session. This isn't limited to OIDC.
* code to token - one time usage
* refresh token - one time usage as well as revocation via logout or
* client initiated linking - new feature. Needs to know that a
particular client is logged in. It also verifies hash based on
client session code.
* logout - minimally needs list of clients to push logout event to.
Maybe also client specific session information?
* broker logout - need to know what broker logged in the user so that
logout event can be pushed to parent IDP. Also need to know
broker's session id.
* step-up authentication - we'll have to know how the user was
previously authenticated in the session.
* no-import broker login - we will need to store external user info in
Is there any more?
On 3/22/17 3:49 AM, 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
> 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.
> 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