Yes, security is another thing, which I was slightly worried regarding
this. +1 to first try on-demand replication approach.
Marek
On 23/05/17 12:29, Schuster Sebastian (INST/ESY1) 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 | 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 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