[keycloak-dev] Cross-DC and codeToToken request

Tue May 23 09:11:07 EDT 2017

No reason the code couldn't be "smarter" though.  Something simple and 
signed that has balancing/routing information in it.

On 5/23/17 2:32 AM, Schuster Sebastian (INST/ESY1) wrote:
> I would like to argue against 1). Putting token content into the authcode kind of changes the flow to be more like the implicit flow.
> OIDC/OAuth2 offers the code flow especially to protect information in the tokens. Some claims could be sensitive and/or personal information
> and I think they should not be in the code. Furthermore, enforcing the single use of codes becomes even harder if they can be exchanged
> to tokens without looking up state first. Relaxing the one-time requirement is clearly against the spec and one should at least try hard to
> fulfill it IMHO.
>
> Best regards,
> Sebastian
>
> Mit freundlichen Grüßen / Best regards
>
>   Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785 Berlin | GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
>> -----Original Message-----
>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
>> bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
>> Sent: Montag, 22. Mai 2017 19:30
>> To: Bill Burke <bburke at redhat.com>
>> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>
>> On 22 May 2017 at 15:16, Bill Burke <bburke at redhat.com> wrote:
>>
>>>
>>> On 5/22/17 3:30 AM, 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?
>>>>
>>>> I reckon protocol mappers should be refactored regardless though.
>>>> The details should be in the code and token not in the user session.
>>> For protocol mappers, the reason why the user session need to be
>>> available is that some component might be storing temporary
>>> information within the session that needs to be mapped to the token.
>>> Any example is a broker login that doesn't want or need to import into
>>> database, but instead stores in in the session.  Doesn't kerberos
>>> store stuff in the session that can be mapped to the token?  Finally,
>>> eventually we will want import-less brokering where the user is
>>> created within the session and destroyed with the session so we dont' have to hit
>> the DB and import.
>> True, so we basically will need to make sure the user session exists and is
>> persisted. I reckon on-demand replication if technically possible the best option.
>>
>>
>>>>> 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.
>>> imo, this is something that should be added to the spec.  That the
>>> code contains the callback 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..
>>>>>
>>>> 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
>>> I think 1 and 4 will hobble us for future things we want to do.
>>>
>>> Bill
>>> _______________________________________________
>>> 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