Hi Vittorio, Yeah, I’m concerning user & client ids collision. I haven’t seen such implementations, but user-select username as sub, or incremental integer as sub & client_id will be easily collide.
If you can enforce collision resistant IDs between user & client instances, it’ll works fine. I feel its overkill though. Sent from my iPhone > On Mar 26, 2019, at 8:51, Vittorio Bertocci <vitto...@auth0.com> wrote: > > Hey Nov, Dominick, Hans- > thanks for the comments. That was an area I was expecting to cause more > discussion, and I am glad we are having this opportunity to clarify. > The current language in the draft traces the etymology of sub to OpenID > Connect core, hence Dominick observation is on point. However in the > description I express something in line with 7519, which was in fact my > intent. > > The idea was to provide an identifier of the calling subject that is > guaranteed to be present in all cases- this would allow an SDK developer to > use the same code for things like lookups and membership checks regardless of > the nature of the caller (user in a delegated case, app in app-only grants). > The information to discriminate between user and app callers is always > available in the token (say, the caller is a user if sub!=client_id, where > client_id is always guaranteed to be present as well) hence there's no loss > in expressive power, should that difference be relevant for the resource > server. > > Dominick, Hans- I probably missed the security issue you guys are thinking of > in this case. Of course, if this would introduce a risk I completely agree it > should be changed- I'd just like to understand better the problem. Could you > expand it in a scenario/use case to clarify the risk? > Nov- playing this back: is the concern that a user and a client might have > the same identifier within an IDP? When using collision resistant IDs, as it > is usually the case, that seems to be a remote possibility- did you stumble > in such scenario in production? > > Thanks > V. > > >> On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt <hans.zandb...@zmartzone.eu> >> wrote: >> I believe there are plenty of OAuth 2.0 only use cases out there... but >> nevertheless I agree with the potential confusion and thus security problems >> arising from that (though one may argue the semantics are the same). >> >> Hans. >> >>> On Mon, Mar 25, 2019 at 3:39 PM Dominick Baier <dba...@leastprivilege.com> >>> wrote: >>> Yes I know - and I think in hindsight it was a mistake to use the same >>> claim type for multiple semantics. >>> >>> All the “this is OIDC not OAuth” arguments are making things more >>> complicated than they need to be - in my experience almost no-one (that I >>> know) does OIDC only - nor OAuth only. They always combine it. >>> >>> In reality this leads to potential security problems - this spec has the >>> potential to rectify the situation. >>> >>> Dominick >>> >>>> On 25. March 2019 at 14:58:56, Hans Zandbelt (hans.zandb...@zmartzone.eu) >>>> wrote: >>>> >>>> Without agreeing or disagreeing: OIDC does not apply here since it is not >>>> OAuth and an access token is not an id_token. >>>> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2: >>>> >>>> "The "sub" (subject) claim identifies the principal that is the >>>> subject of the JWT. The claims in a JWT are normally statements >>>> about the subject. The subject value MUST either be scoped to be >>>> locally unique in the context of the issuer or be globally unique. >>>> The processing of this claim is generally application specific" >>>> >>>> which kind of spells "client" in case of the client credentials grant but >>>> I also do worry about Resource Servers thinking/acting only in terms of >>>> users >>>> >>>> Hans. >>>> >>>>> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier >>>>> <dba...@leastprivilege.com> wrote: >>>>> IMHO the sub claim should always refer to the user - and nothing else. >>>>> >>>>> OIDC says: >>>>> >>>>> "Subject - Identifier for the End-User at the Issuer." >>>>> >>>>> client_id should be used to identify clients. >>>>> >>>>> cheers >>>>> Dominick >>>>> >>>>>> On 25.. March 2019 at 05:13:03, Nov Matake (mat...@gmail.com) wrote: >>>>>> >>>>>> Hi Vittorio, >>>>>> >>>>>> Thanks for the good starting point of standardizing JWT-ized AT. >>>>>> >>>>>> One feedback. >>>>>> The “sub” claim can include 2 types of identifier, end-user and client, >>>>>> in this spec. >>>>>> It requires those 2 types of identifiers to be unique each other in the >>>>>> IdP context. >>>>>> >>>>>> I prefer omitting “sub” claim in 2-legged context, so that no such >>>>>> constraint needed. >>>>>> >>>>>> thanks >>>>>> >>>>>> nov >>>>>> >>>>>>> On Mar 25, 2019, at 8:29, Vittorio Bertocci >>>>>>> <vittorio.bertocci=40auth0....@dmarc.ietf.org> wrote: >>>>>>> >>>>>>> Dear all, >>>>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 access >>>>>>> tokens. You can find it in >>>>>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/. >>>>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting >>>>>>> remotely). I look forward for your comments! >>>>>>> >>>>>>> Here's just a bit of backstory, in case you are interested in how this >>>>>>> doc came to be. The trajectory it followed is somewhat unusual. >>>>>>> Despite OAuth2 not requiring any specific format for ATs, through the >>>>>>> years I have come across multiple proprietary solution using JWT for >>>>>>> their access token. The intent and scenarios addressed by those >>>>>>> solutions are mostly the same across vendors, but the syntax and >>>>>>> interpretations in the implementations are different enough to prevent >>>>>>> developers from reusing code and skills when moving from product to >>>>>>> product. >>>>>>> I asked several individuals from key products and services to share >>>>>>> with me concrete examples of their JWT access tokens (THANK YOU >>>>>>> Dominick Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel >>>>>>> Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and >>>>>>> explanations!). >>>>>>> I studied and compared all those instances, identifying commonalities >>>>>>> and differences. >>>>>>> I put together a presentation summarizing my findings and suggesting a >>>>>>> rough interoperable profile (slides: >>>>>>> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx >>>>>>> ) - got early feedback from Filip Skokan on it. Thx Filip! >>>>>>> The presentation was followed up by 1.5 hours of unconference >>>>>>> discussion, which was incredibly valuable to get tight-loop feedback >>>>>>> and incorporate new ideas. John Bradley, Brian Campbell Vladimir >>>>>>> Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were >>>>>>> all there and contributed generously to the discussion. Thank you!!! >>>>>>> Note: if you were at OSW2019, participated in the discussion and didn't >>>>>>> get credited in the draft, my apologies: please send me a note and I'll >>>>>>> make things right at the next update. >>>>>>> On my flight back I did my best to incorporate all the ideas and >>>>>>> feedback in a draft, which will be discussed at IETF104 tomorrow. >>>>>>> Rifaat, Hannes and above all Brian were all super helpful in >>>>>>> negotiating the mysterious syntax of the RFC format and submission >>>>>>> process. >>>>>>> I was blown away by the availability, involvement and willingness to >>>>>>> invest time to get things right that everyone demonstrated in the >>>>>>> process. This is an amazing community. >>>>>>> V. >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> -- >>>> hans.zandb...@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >> >> >> -- >> hans.zandb...@zmartzone.eu >> ZmartZone IAM - www.zmartzone.eu
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
