Hi Neil, you raised a very important issue but the Security BCP does not talk about JWT content like the Access Token JWT BCP.
I therefore think the security advise should go into the security considerations section of the Access Token JWT BCP. best regards, Torsten. > Am 07.05.2019 um 11:18 schrieb Neil Madden <neil.mad...@forgerock.com>: > > Is it too late to add the observation below to the OAuth security topics BCP > draft? > > >> Begin forwarded message: >> >> From: Neil Madden <neil.mad...@forgerock.com> >> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >> Date: 7 May 2019 at 09:37:29 BST >> To: Vittorio Bertocci <Vittorio=40auth0....@dmarc.ietf.org> >> Cc: Hans Zandbelt <hans.zandb...@zmartzone.eu>, Karl McGuinness >> <kmcguinn...@okta.com>, John Bradley <ve7...@ve7jtb.com>, IETF oauth WG >> <oauth@ietf.org> >> >> I wasn’t at IIW so I may be missing some context. >> >> There is a potential security issue if the client_id is used as the “sub” >> for an AT obtained via client_credentials. If the client can register itself >> with a self-chosen client_id then it may deliberately chose a client_id that >> matches the user name of a privileged user. An RS that just blindly looks at >> the “sub” claim may then erroneously let the client perform privileged >> actions. >> >> Is this the context of the discussion? >> >> Given that there are a lot of RSes in existence, many of which are probably >> just looking at the “sub” claim to identify the resource owner, I think the >> onus is on the AS to ensure that no such ambiguity can arise in the first >> place by ensuring that the space of “sub” values for client credentials is >> disjoint with the space for genuine users or by disallowing the >> client_credentials grant altogether. >> >> This issue already arises in token introspection though, so maybe ought to >> be mentioned in the OAuth security topics draft rather than specific to the >> JWT AT draft? >> >> — Neil >> >>> On 6 May 2019, at 18:32, Vittorio Bertocci >>> <Vittorio=40auth0....@dmarc..ietf.org> wrote: >>> >>> Hi all, >>> thanks for your patience during this month long hiatus, and thanks for the >>> comments. >>> Last week at IIW I had the opportunity to discuss this with many of the >>> people on the list. Here's a summary of where the discussion landaed on the >>> subject of the sub (pun intended). >>> >>> - It seems that RFC 7519 has pretty clear language on the use of sub- I >>> didn't check it back when we started the discussion. I do agree with the >>> people saying that we shouldn't violate existing specifications, hence it >>> looks like we do need to have sub also in the case in which we have >>> app-only tokens carrying claims about the app itself. I understand this >>> will cause some implementation to break, but unfortunately that's intrinsic >>> in the process of coming up with a common approach and standards compliance >>> is probably one of the strongest reasons to tolerate that. >>> - That said, I am strongly committed to preserve existing functionality. >>> One of the main reasons that was brought up for including sub only for user >>> based ATs was to use it as heuristic for telling those tokens apart from >>> app-only ones. To that end, Karl MCGuinness suggested that we include >>> grant_type as a return claim, which the RS could use to the same effect. I >>> find the proposal very clever, and the people at IIW thought so as well. >>> What you think? >>> Note, John Bradley observed that in some cases this might lead to ambiguous >>> results if an extension grant is used (say an assertion profile) but that >>> seems like a relatively fringe occurrence. >>> >>>> On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt <hans.zandb...@zmartzone.eu> >>>> wrote: >>>> I also meant to say that (of course) the JWT standard doesn't say that the >>>> JWT is supposed to be about the client or about the resource owner, hence >>>> both are valid >>>> >>>> Hans. >>>> >>>>> On Thu, Apr 4, 2019 at 10:09 PM Mike Jones <michael.jo...@microsoft.com> >>>>> wrote: >>>>> I get that existing practice is likely to be all over the map, but if >>>>> we’re to create a JWT access token standard, it’s reasonable to require >>>>> that the claims usage comply with the JWT standards. >>>>> >>>>> >>>>> >>>>> -- Mike >>>>> >>>>> >>>>> >>>>> From: Hans Zandbelt <hans.zandb...@zmartzone.eu> >>>>> Sent: Thursday, April 4, 2019 12:59 PM >>>>> To: Mike Jones <michael.jo...@microsoft.com> >>>>> Cc: George Fletcher <gffletch=40aol....@dmarc.ietf.org>; Vittorio >>>>> Bertocci <Vittorio=40auth0....@dmarc.ietf.org>; IETF oauth WG >>>>> <oauth@ietf.org> >>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >>>>> >>>>> >>>>> >>>>> the definition of RFC 7519 is actually "petitio principii" and a lot of >>>>> deployments put claims about the Resource Owner in the access token (as a >>>>> Resource Server implementer I've suffered a lot from this) >>>>> >>>>> >>>>> >>>>> Hans. >>>>> >>>>> >>>>> >>>>> On Thu, Apr 4, 2019 at 9:48 PM Mike Jones <michael.jo...@microsoft.com> >>>>> wrote: >>>>> >>>>> I agree with George that the subject of a token must be the principal of >>>>> that token. That what the JWT “sub” claim is for. Indeed, the first >>>>> sentence of the “sub” definition at >>>>> https://tools.ietf.org/html/rfc7519#section-4.1.2 is: >>>>> >>>>> The "sub" (subject) claim identifies the principal that is the subject of >>>>> the JWT. >>>>> >>>>> >>>>> >>>>> If an access token uses “sub”, its usage must comply with the definition >>>>> from RFC 7519. >>>>> >>>>> >>>>> >>>>> -- Mike >>>>> >>>>> >>>>> >>>>> From: OAuth <oauth-boun...@ietf.org> On Behalf Of George Fletcher >>>>> Sent: Thursday, April 4, 2019 8:51 AM >>>>> To: Hans Zandbelt <hans.zandb...@zmartzone.eu> >>>>> Cc: Vittorio Bertocci <Vittorio=40auth0....@dmarc.ietf.org>; IETF oauth >>>>> WG <oauth@ietf.org> >>>>> Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 >>>>> >>>>> >>>>> >>>>> The more I think about this the more I land in the "No" camp. >>>>> >>>>> The subject of a token should be the principal of that token. It >>>>> shouldn't matter whether that is a machine, a user, or a device. Trying >>>>> to separate out "humans" as a special class will just make things more >>>>> complicated. If we need a claim to identify the subject is a "human" then >>>>> why not just add that. This doesn't break anything and makes it easy for >>>>> people to detect this case in those use cases where it's required. >>>>> >>>>> Thanks, >>>>> George >>>>> >>>>> On 4/3/19 4:56 PM, Hans Zandbelt wrote: >>>>> >>>>> I will argue that in a way such deployments are already broken e.g. in >>>>> the typical use case of onboarding client accounts in the same >>>>> directory/OU/namespace as user accounts and we don't need to cater for >>>>> that. >>>>> >>>>> >>>>> >>>>> Hans. >>>>> >>>>> >>>>> >>>>> On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <gffle...@aol.com> wrote: >>>>> >>>>> I agree that this will break a lot of existing flows... especially those >>>>> using any form of the client_credentials flow. In that sense I'm not >>>>> completely on board yet :) >>>>> >>>>> On 3/26/19 12:56 PM, Hans Zandbelt wrote: >>>>> >>>>> great summary! this will hurt quite a few existing m2m deployments but I >>>>> do like the rigidness of it all: it is very explicit, cannot >>>>> misinterpreted and thus prevents failure (which is really what Dominick >>>>> is after); I'm on board >>>>> >>>>> >>>>> >>>>> Hans. >>>>> >>>>> >>>>> >>>>> On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci >>>>> <Vittorio=40auth0....@dmarc.ietf.org> wrote: >>>>> >>>>> thank you Steinar and everyone else for the comments on this! >>>>> >>>>> To summarize the situation so far: Dominick, Steinar, Rob, David, Nov, >>>>> Bertrand recommend using sub only for users. Martin would like to have >>>>> the sub for app only flows as well. Hans is neutral. >>>>> >>>>> That does sound like the sub as user has more consensus, tho before >>>>> changing it I'd wait for the people currently at IETF104 to have more >>>>> time to comment as well. >>>>> >>>>> Clarification. If the goal is to be able to apply the logic "if there's a >>>>> sub, it's a user flow", we have to explicitly disallow (MUST NOT) the use >>>>> of sub when that's not the case. Are all OK with it? >>>>> >>>>> >>>>> >>>>> Dave, the suggestion of having explicit typing for app only vs user only >>>>> is interesting! For the purpose of putting together an interoperable >>>>> profile, tho, I would suggest we table it for v1 in the interest of >>>>> getting to something easy to adopt (hence with small delta vs existing >>>>> implementations) faster. >>>>> >>>>> >>>>> >>>>> On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem <stei...@udelt.no> wrote: >>>>> >>>>> Hi Vittorio, we (the national federation-gateway for the health services >>>>> in norway - "HelseID") think his is a really valuable initiative! >>>>> >>>>> We also agree with Dominick concerning definition of the "sub" claim. >>>>> >>>>> >>>>> >>>>> <mvh>Steinar</mvh> >>>>> >>>>> >>>>> >>>>> tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier >>>>> <dba...@leastprivilege.com>: >>>>> >>>>> From an access token consumer (aka API) developer point of view, I prefer >>>>> this logic >>>>> >>>>> >>>>> >>>>> "If sub is present - client acts on behalf of a user, if not - not." >>>>> >>>>> >>>>> >>>>> Anything more complicated has a potential of going wrong. >>>>> >>>>> >>>>> >>>>> On 26. March 2019 at 01:34:53, Nov Matake (mat...@gmail.com) wrote: >>>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Vennlig hilsen >>>>> >>>>> >>>>> >>>>> Steinar Noem >>>>> >>>>> Partner Udelt AS >>>>> >>>>> Systemutvikler >>>>> >>>>> >>>>> >>>>> | stei...@udelt.no | h...@udelt.no | +47 955 21 620 | www.udelt.no | >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> hans.zandb...@zmartzone.eu >>>>> >>>>> ZmartZone IAM - www.zmartzone.eu >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>> >>>> >>>> -- >>>> hans.zandb...@zmartzone.eu >>>> ZmartZone IAM - www.zmartzone.eu >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
