From: Sander A. <sa....@fz...> - 2022-03-01 08:46:36
|
Good morning, a short addition. It is not only the oidc-agent witch has a problem with the token size. EUDAT B2SAFE has it as well because they use the token as password in iRODS and this has also limitations in size. And yes the most problems for switching the scopes would be for the users of the oidc-agent. Because all other set them once. Best regards, Sander On Mon, 2022-02-28 at 12:34 +0100, Marcus Hardt wrote: > On 28. Feb 2022 12:11, Krzysztof Benedyczak wrote: > > Hi Marcus, > > > > W dniu 23.02.2022 o 18:06, Marcus Hardt pisze: > > > Hi Krzysztof, > > > > > > > > > On 23. Feb 2022 16:08, Krzysztof Benedyczak wrote: > > > > Hi, > > > > > > > > I'm leaving the longer thread below for reference, however the > > > > main open > > > > point is how to specify what should land in JWT-style access > > > > token. > > > > I see no security implications here, so that's not a problem. > > > > > > > > From what you wrote configuring that via scopes is not great > > > > as would make > > > > it hard for the clients. > > > I'm not sure I understand. Requesting specific scopes is in the > > > standard. > > > I understand that the problem is which claims go into jwt AT and > > > which > > > ones are in the userinfo-endpoint, right? > > > > Requesting scopes is in the standard, that's no problem. But as I > > understood > > Sander (and also can imagine on my own) that's bit of an > > organizational > > problem. > > > > Let's assume Unity allows admin to configure per scope, whether > > attributes > > of that scope should go to AT or not. Now, if you have clients that > > require > > no extra claims in AT and some with opposite requirement, then you > > will need > > to create a duplicate of each scope in Unity: > > > > profile; profile_in_at > > > > job_info; job_info_in_at > > > > ... which will differ only with that setting. Clunky, both from > > server side > > and client side. > > Hmm. Another clarification (that isn't 100% clear, maybe): I think > this > problem mostly relates to a single client-id: oidc-agent, as this is > the > one used in many use-cases that involving delegation. > > > Also a small clarification: user-info endpoint will always return > > all > > claims. The only problem to decide is which claims also are put > > into JWT AT. > > Ok; > > After thinking a bit, I think it might be best to keep both sets > equal. > One (the main showstopper?) for AT<1K is our own application, and we > do > have an inimplemented workaround. I think we'll have that done in > like 4 > months (because there is more pressing stuff around). > > > > > Configuring per client is not acceptable as the same client may > > > > operate in > > > > different contexts and in some it is using some dumb services > > > > which have a > > > > limit on access token size. > > > Yes. Fully agree. > > > > So what are the proposals here? Use some proprietary request > > > > parameter for > > > > it? > > > I really don't know. If this is really about which scopes go into > > > which > > > place (JWT vs userinfo), then something proprietary might not be > > > so > > > harmful. I'm sure this question will bother others, too. > > > > > > > > > One way out, could be to live with the long ATs. > > > > > > I'll check with our OIDC expert, but this won't turn around > > > before monday. > > > > > > OK, let us know. > > > > If thinking about proprietary solution, I think we can have it. > > However I'd > > keep it dead simple: just a flag "uy_put_claims_in_access_token", > > which > > would put all claims in AT. > > He suggested using the same mechanism as in the "claims" place, but > using > a different keyword. > > He sends this reference: > https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter > > Maybe just calling it "claims_at" would be all it takes. > -- Federated Systems and Data Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Volker Rieke Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior ----------------------------------------------------------------------- ----------------------------------------------------------------------- |