grant_type would be horrible for RS developers to deal with, just to
find out whether "sub" effectively == "client_id".
Why?
* RS developers will need to learn more OAuth stuff - there are better
ways to motivate people than that :)
* The OAuth grant types are unbounded. If at some point a new grant
gets devised / implemented, RS developers will need to update the
code that maps grant_types to ("sub" effectively == "client_id")
* We have at least one grant - JWT assertion - where checking the
grant type is not sufficient to determine if "sub" effectively ==
"client_id"
I believe we should aim for a spec where RS developers shouldn't be
required to know more than how to process JWTs.
The AS has all the necessary information to indicate whether "sub"
effectively == "client_id". We don't need to push that logic to the RS.
Vladimir
On 07/05/2019 12:16, Neil Madden wrote:
> Ah, that makes sense. Well, we already add a grant_type claim to our
> JWT-based access tokens, so I’m in favour of that solution :-)
>
>
>> On 7 May 2019, at 09:48, Vittorio Bertocci <vitto...@auth0.com> wrote:
>>
>> Thanks Neil, one more reason to avoid that.
>> TL;DR,
>> The context is the discussion we had pre-IIW about whether sub should be
>> included always or only for tokens issued to ROs. Some exiting
>> implementations rely on that heuristic.
>> Turns out that 7519 has language suggesting sub should be there for both
>> tokens issued for the RO and for apps (via client creds, etc).
>> We don't want to contradict 7519 but we also want to preserve the ability
>> for a RS to tell whether an AT was issued via RO auth or app auth, hence the
>> discussion. Suggestions ranged from adding a grant_type claim (Vlad made a
>> convincing argument against it), to relying to the client_id==sub heuristic
>> (which i pushed back on) to the introduction of a new claim (name TBD given
>> that sub_type is taken already) that can explicitly declare whether the
>> token has been issued authenticating th RO or via app credentials.
>>
>> On Tue, May 7, 2019 at 1:37 AM Neil Madden <neil.mad...@forgerock.com
>> <mailto:neil.mad...@forgerock.com>> wrote:
>> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
