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