[keycloak-dev] Cross-DC and codeToToken request

[Stian Thorgersen]

On 19 May 2017 at 10:24, Marek Posolda <mposolda at redhat.com> wrote:

> Followup on some previous emails I sent this week around sticky sessions
> and OIDC backchannel requests.
>
> In shortcut, it would be ideal if we can achieve that backchannel
> requests (code-to-token, refresh token, logouts etc) can participate in
> same sticky session like the browser request. It may be possible in some
> cases (our adapters, some loadbalancers, see previous email I sent this
> week) but not everytime. And looks we would need to support the case
> when it's not possible.
>
> I can start with code-to-token request as it's slightly more complicated
> then the others due to the reasons:
>
> 1) code must be single-use per OAuth2 / OIDC specification
>
> 2) userSession may not yet be available. In case that we use ASYNC
> channel for communication between datacenters for transfer userSession
> (which I think should be the default due to performance reasons), then
> this example flow can happen:
> - user successfully authenticated and userSession was created on DC1.
> - code-to-token request is sent by the adapter to DC2. Note that this
> request is usually sent very quickly after userSession is created.
> - DC2 didn't yet received the message from DC1 about the new
> userSession. So this userSession not yet available here.
>
> Questions:
> 1) Could we remove a need from code-to-token endpoint to lookup
> userSession? I see this as an option as long as code itself is JWT
> signed with realm HMAC key encapsulating some info about user,
> session_state etc. Among other things, this would require some
> refactoring of protocolMappers (as userSession won't be available when
> tokens are generated). But isn't it bad for security to have some claims
> directly to the code? It is query parameter, which may end visible in
> browser history. IMO this is not big issue, but not 100% sure..
>

Wouldn't the code also become rather big?

I reckon protocol mappers should be refactored regardless though. The
details should be in the code and token not in the user session.


>
> 2) Another option is let the code-to-token endpoint wait until
> userSession is available. Then we would need support for asynchronous
> requests? I can see blocking undertow workers in waiting (something
> based on java.util.concurrent.Future) can be an issue and potential for
> DoS? Still even with asynchronous, the request times can be quite long.
>

I like this option. Could we combine this with on demand replication? With
a configurable timeout this would be nifty IMO.


>
> 3) Can we encourage people to use sticky sessions at least for
> code-to-token endpoint? We can add the route directly to the code
> itself, so the URL will look like:
> http://apphost/app?code=123.node1&state=456 . Many loadbalancers seem to
> support sticky session based on URL part. But there is also
> response_mode=form_post when the code won't be available in the URI.


May work for some, but I doubt it'll work for everyone.


>
> 4) Is it ok to have option to relax on code one-time use? Otherwise in
> cross-DC and without sticky session, the every code exchange may require
> SYNC request to another DCs to doublecheck code was not used already.
> Not good for performance..
>

Maybe this is OK. Confidential apps needs credentials and then
there's Proof Key for Code Exchange for public clients. Although the latter
may be another issue in cross-DC?


>
> For now, I can see some combination of 1,3,4 as a way to go. WDYT?
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>