[keycloak-dev] Cross-DC and codeToToken request
Marek Posolda
mposolda at redhat.com
Wed May 24 03:02:22 EDT 2017
There were 2 cases to consider:
- Code-to-token endpoint won't have userSession available. In this case,
code would need to contain actual claims. At least some of them, which
require userSession. But we agreed to not go this path, at least not now?
- Code-to-token endpoint will have userSession available. In this case,
code doesn't need to contain any claims of user. Just the sessionState
and possibly route info. Code-to-token endpoint will lookup userSession,
user, and all the stuff it needs to generate claims into the tokens.
Pretty much like it's now.
I was also thinking, that code is slightly modified JWT and also
contains route information in the path itself. Like:
code=jwt-header.jwt-content.jwt-hmac-signature.route-info . The route
info in the URL has advantage that some loadbalancers might be able to
read it from there and route the request. Lookup into JWT is slightly
more tricky and loadbalancers won't support it unless it's some
loadbalancer/smart proxy developed by us. Anyway, not everyone would
like to have the route in the URL, like Sebastian I guess? Maybe code
generation and parsing deserves to be externalized with the separate SPI?
Marek
On 24/05/17 06:25, 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
> <mailto: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
>> <mailto: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
>> <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 at bosch-si.com
>> <mailto: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>
>> [mailto:keycloak-dev- <mailto:keycloak-dev->
>> >bounces at lists.jboss.org <mailto:bounces at lists.jboss.org>] On
>> Behalf Of Marek Posolda
>> > Sent: Dienstag, 23. Mai 2017 10:41
>> > To: Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>>; keycloak-dev at lists.jboss.org
>> <mailto: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
>> <mailto:keycloak-dev at lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>
More information about the keycloak-dev
mailing list