The same issue applies to token introspection responses though. > On 7 May 2019, at 12:21, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > > 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 > <mailto: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 >>> <mailto: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 >>> <mailto:Vittorio=40auth0....@dmarc.ietf.org>> >>> Cc: Hans Zandbelt <hans.zandb...@zmartzone.eu >>> <mailto:hans.zandb...@zmartzone.eu>>, Karl McGuinness <kmcguinn...@okta.com >>> <mailto:kmcguinn...@okta.com>>, John Bradley <ve7...@ve7jtb.com >>> <mailto:ve7...@ve7jtb.com>>, IETF oauth WG <oauth@ietf.org >>> <mailto: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 >>>> <mailto: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 >>>> <mailto: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 >>>> <mailto: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 >>>> <mailto:hans.zandb...@zmartzone.eu>> >>>> Sent: Thursday, April 4, 2019 12:59 PM >>>> To: Mike Jones <michael.jo...@microsoft.com >>>> <mailto:michael.jo...@microsoft.com>> >>>> Cc: George Fletcher <gffletch=40aol....@dmarc.ietf.org >>>> <mailto:40aol....@dmarc...ietf.org>>; Vittorio Bertocci >>>> <Vittorio=40auth0....@dmarc.ietf.org <mailto:40auth0....@dmarc.ietf.org>>; >>>> IETF oauth WG <oauth@ietf.org <mailto: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 >>>> <mailto: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 >>>> <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 <mailto:oauth-boun...@ietf.org>> On >>>> Behalf Of George Fletcher >>>> Sent: Thursday, April 4, 2019 8:51 AM >>>> To: Hans Zandbelt <hans.zandb...@zmartzone.eu >>>> <mailto:hans.zandb...@zmartzone.eu>> >>>> Cc: Vittorio Bertocci <Vittorio=40auth0....@dmarc.ietf.org >>>> <mailto:40auth0....@dmarc.ietf.org>>; IETF oauth WG <oauth@ietf.org >>>> <mailto: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 >>>> <mailto: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 <mailto: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 >>>> <mailto: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 <mailto: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 >>>> <mailto: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 >>>> <mailto: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 >>>> <mailto: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 >>>> <mailto: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 >>>> <mailto: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 >>>> <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 >>>> <mailto: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 >>>> <mailto: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 >>>> <mailto: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/ >>>> <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 >>>> >>>> <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 <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>>> >>>> >>>> -- >>>> >>>> hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu> >>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> >>>> >>>> >>>> >>>> -- >>>> >>>> hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu> >>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>>> >>>> >>>> -- >>>> >>>> Vennlig hilsen >>>> >>>> >>>> >>>> Steinar Noem >>>> >>>> Partner Udelt AS >>>> >>>> Systemutvikler >>>> >>>> >>>> >>>> | stei...@udelt.no <mailto:stei...@udelt..no> | h...@udelt.no >>>> <mailto:h...@udelt.no> | +47 955 21 620 | www.udelt.no >>>> <http://www.udelt.no/> | >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>>> >>>> >>>> -- >>>> >>>> hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu> >>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu> >>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu> >>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> >>>> >>>> -- >>>> hans.zandb...@zmartzone.eu <mailto:hans.zandb...@zmartzone.eu> >>>> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
