[keycloak-dev] Cross-DC and codeToToken request

[Stian Thorgersen]

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

> We've talked about this earlier in the thread.  The User session is needed
> as brokering or some other component might have stored temporary data
> within the user session that is being mapped to a claim.  This will become
> especially important when we implement no-import brokering.  Either the
> code has to contain all claims, or the user session has to be available.
>
That's the part that I don't understand. Why would it even contain anything
if the code is just a permission to obtain a token. We invoke any protocol
mappers or anything until the first token is created.

> IMO, the most viable solution is that the code contains routing
> information and the code-to-token endpoint acts as a proxy if the session
> doesn't exist on that node.
>
> On 5/24/17 12:25 AM, Stian Thorgersen wrote:
>
> I meant if we are planning to change it. I don't see why it would need to
> contain actual claims, but rather could it not just contain the details to
> generate the claims?
>
> On 23 May 2017 at 21:43, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Nope, right now OAuth code just references userSession and client. ATM
>> code itself is not JWT.
>>
>> Marek
>>
>>
>> On 23/05/17 14:55, Stian Thorgersen wrote:
>>
>> Marek - are we not just storing the details we need to know what mappers
>> to invoke? There's no actually claims in there right?
>>
>> On 23 May 2017 at 12:29, Schuster Sebastian (INST/ESY1) <
>> Sebastian.Schuster at bosch-si.com> wrote:
>>
>>> Another argument against providing claims in the code is that it can be
>>> stolen by rogue mobile apps and PKCE does not help here as it only prevents
>>> using stolen codes. Encrypting the code could help, but this might also
>>> have impact on code size. Maybe it is best to first try the on-demand
>>> replication approach and see if it nails it before introducing another
>>> configuration switch that could be set wrong and the associated code?
>>>
>>> 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 <%2B49%2030%20726112-485> | Fax +49 30 726112-100
>>> <%2B49%2030%20726112-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 Marek Posolda
>>> > Sent: Dienstag, 23. Mai 2017 10:41
>>> > To: Bill Burke <bburke at redhat.com>; keycloak-dev at lists.jboss.org
>>> > Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
>>> >
>>> > On 22/05/17 15:16, Bill Burke wrote:
>>> > >>> 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.
>>> >
>>> > Ok, I understand 1 may be problematic for some scenarios and won't do
>>> it. But
>>> > what exactly is a blocker for relax on code one-time use?
>>> >
>>> > I am thinking that code will be still single-use by default as it's
>>> required per
>>> > OAuth2/OIDC specs. However admins, who prefer performance over
>>> security, may
>>> > choose to relax strict code one-time use. This may be new option - not
>>> sure
>>> > whether configurable per realm or per client. I can see it's likely ok
>>> in some
>>> > environments (private corporate networks
>>> > etc) ?
>>> >
>>> > Marek
>>> >
>>> > _______________________________________________
>>> > 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
>>>
>>
>>
>>
>
>