Wouldn’t that mean it would have to hit the database or Infinispan to retrieve additional
information from somewhere or are protocol mappers pure functions? In the first case,
storing additional information in the code is not that helpful anymore as state needs to
be retrieved anyways. In the second case, the code would have to be encrypted as an
attacker could derive claims from details in the code, too.
I actually started wondering whether code-to-token is a good use case for
retrieving/caching the user session. I would assume the client holds on to a token it
retrieved until it expires which means it might not come back to the token endpoint until
its DNS cache expires, possibly causing it to end up at another DC next time it comes
back. Depends on token lifetime vs. DNS cache expiration, of course. On the other hand, it
might go to the userinfo endpoint in between…
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<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn
From: Stian Thorgersen [mailto:sthorger@redhat.com]
Sent: Mittwoch, 24. Mai 2017 06:25
To: Marek Posolda <mposolda(a)redhat.com>
Cc: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster(a)bosch-si.com>; Bill Burke
<bburke(a)redhat.com>; keycloak-dev(a)lists.jboss.org
Subject: Re: [keycloak-dev] Cross-DC and codeToToken request
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@redhat.com<mailto:mposolda@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@bosch-si.com<mailto:Sebastian.Schuster@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<http://www.bosch-si.com>
Tel. +49 30 726112-485<tel:%2B49%2030%20726112-485> | Fax +49 30
726112-100<tel:%2B49%2030%20726112-100> |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@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@lists.jboss.org<mailto:keycloak-dev-bounces@lists.jboss.org>
[mailto:keycloak-dev-<mailto:keycloak-dev->
bounces@lists.jboss.org<mailto:bounces@lists.jboss.org>] On Behalf Of Marek
Posolda
Sent: Dienstag, 23. Mai 2017 10:41
To: Bill Burke <bburke@redhat.com<mailto:bburke@redhat.com>>;
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@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@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev