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

[Bill Burke]

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
    other mechanism
  * 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
    a session.

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
> leaked.
>
> 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.
>
> 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