[keycloak-dev] Cross-DC and codeToToken request

[Marek Posolda]

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