[keycloak-dev] Cross-DC and codeToToken request

[Stian Thorgersen]

On 23 May 2017 at 11:16, Marek Posolda <mposolda at redhat.com> wrote:

> On 22/05/17 09:30, Stian Thorgersen wrote:
>
>
>
> 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?
>
> 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 . 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.
>

Probably not a new problem, but it's yet another update to user session.


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