Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Hans Zandbelt <[e-mail]>]

I agree with Vladimir: we don't want the RS to know about grant types since
these are extensible and there may be more than one grant type that has
client credentials like semantics [1]

Hans.

[1] I can think of a new "referred_client_credentials" grant type that
doesn't return its tokens directly from the token endpoint but refers to a
remote endpoint and hands out creds for the call to that endpoint


On Tue, May 7, 2019 at 10:16 AM Neil Madden <[e-mail]>
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 <[e-mail]> 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 <[e-mail]>
> 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=[e-mail]> 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 <[e-mail]>
>> 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 <[e-mail]>
>>> 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 <[e-mail]>
>>>> *Sent:* Thursday, April 4, 2019 12:59 PM
>>>> *To:* Mike Jones <[e-mail]>
>>>> *Cc:* George Fletcher <gffletch=[e-mail]
>>>> <40aol.com@dmarc...ietf.org>>; Vittorio Bertocci <Vittorio=
>>>> [e-mail]>; IETF oauth WG <[e-mail]>
>>>> *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 <[e-mail]>
>>>> 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 <[e-mail]> *On Behalf Of *George Fletcher
>>>> *Sent:* Thursday, April 4, 2019 8:51 AM
>>>> *To:* Hans Zandbelt <[e-mail]>
>>>> *Cc:* Vittorio Bertocci <Vittorio=[e-mail]>; IETF
>>>> oauth WG <[e-mail]>
>>>> *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 <[e-mail]>
>>>> 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=
>>>> [e-mail]> 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 <[e-mail]> 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 <
>>>> [e-mail]>:
>>>>
>>>> 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 ([e-mail]) 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 <[e-mail]> 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 <
>>>> [e-mail]> 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 <
>>>> [e-mail]> 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 (
>>>> [e-mail]) 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 <
>>>> [e-mail]> 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 ([e-mail]) 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=[e-mail]> 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
>>>>    <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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> [e-mail]
>>>>
>>>> ZmartZone IAM - www.zmartzone.eu
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> [e-mail]
>>>>
>>>> ZmartZone IAM - www.zmartzone.eu
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Vennlig hilsen
>>>>
>>>>
>>>>
>>>> Steinar Noem
>>>>
>>>> Partner Udelt AS
>>>>
>>>> Systemutvikler
>>>>
>>>>
>>>>
>>>> | [e-mail] <steinar@udelt..no> | [e-mail]  | +47 955 21
>>>> 620 | www.udelt.no |
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> [e-mail]
>>>>
>>>> ZmartZone IAM - www.zmartzone.eu
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> OAuth mailing list
>>>>
>>>> [e-mail]
>>>>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> [e-mail]
>>>>
>>>> ZmartZone IAM - www.zmartzone.eu
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> [e-mail]
>>>>
>>>> ZmartZone IAM - www.zmartzone.eu
>>>>
>>>
>>>
>>> --
>>> [e-mail]
>>> ZmartZone IAM - www.zmartzone.eu
>>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>

-- 
[e-mail]
ZmartZone IAM - www.zmartzone.eu