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(a)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(a)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(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 Marek Posolda
>> > Sent: Dienstag, 23. Mai 2017 10:41
>> > To: Bill Burke <bburke(a)redhat.com>; keycloak-dev(a)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(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
>>
>
>
>