[keycloak-dev] Cross-DC and codeToToken request

[Marek Posolda]

On 22/05/17 09:30, Stian Thorgersen wrote:
>
>
> On 19 May 2017 at 10:24, Marek Posolda <mposolda at redhat.com 
> <mailto: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?
Just did some simple testing. For the HMAC signed code, the code with 10 
JSON claims has:
header size: 84
content size: 524
signature size: 87

Total length of code parameter would be 697 characters. As long as URL 
is shorter than 2000 characters, it should work fine in all the 
browsers, so we should be ok?

Not sure whether we need to use "code as JWT" path. Even if we require 
on-demand replication of userSession and hence the userSession will be 
available in code-to-token endpoint, having code as JWT may be still 
helpful for some things (sticky sessions etc).
>
> 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.
+1
>
>
>     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
>     <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?
You mean that PKCE will be another issue in cross-dc? I am not seeing 
anything more problematic then other scenarios? For server-side, it 
requires userSession available in code-to-token endpoint as that's where 
codeChallenge is saved. However that should be the case anyway.

Marek

>
>     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 <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>