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(a)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(a)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(a)lists.jboss.org [mailto:keycloak-dev-
>> bounces(a)lists.jboss.org] On Behalf Of Stian Thorgersen
>> Sent: Montag, 22. Mai 2017 19:30
>> To: Bill Burke <bburke(a)redhat.com>
>> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
>> Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>
>> On 22 May 2017 at 15:16, Bill Burke <bburke(a)redhat.com> wrote:
>>
>>
>>> On 5/22/17 3:30 AM, Stian Thorgersen wrote:
>>>
>>>> On 19 May 2017 at 10:24, Marek Posolda <mposolda(a)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(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>