[keycloak-dev] Cross-DC and codeToToken request

Tue May 23 14:11:57 EDT 2017

Doesn't the code only have to contain client_id, scope, etc.? Then the
protocol mappers can be evaluated when the token is generated rather than
when the code is generated?

On 23 May 2017 at 15:11, Bill Burke <bburke at redhat.com> wrote:

> 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
>>>
>>
>