[keycloak-dev] Cross-DC and codeToToken request

[Marek Posolda]

Yes, it is in all backchannel requests you mentioned in the other mail. 
Just wanted to start with code-to-token request as it is "special" due 
the fact that:
- code is single-use per specs and this should be ensured for all DCs 
though.
- userSession may not be yet available in case of ASYNC replication. So 
was thinking about possibility to avoid lookup userSession at all in 
code-to-token request (details below) and other options.

Marek

On 19/05/17 15:12, Bill Burke wrote:
> Don't you have same problem with refresh token?
>
>
> On 5/19/17 4:24 AM, Marek Posolda 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..
>>
>> 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.
>>
>> 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.
>>
>> 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..
>>
>> 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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev