[OAUTH-WG] A token review of draft-parecki-oauth-v2-1-01

[Brian Campbell]

Been working on this on and off for a while now (it's not exactly short at
80+ pages, various other priorities, etc.) but wanted to share my thoughts
from an initial review of the OAuth 2.1 draft before the interim next week
where it is on the agenda
https://datatracker.ietf.org/doc/agenda-interim-2020-oauth-06-oauth-01/.
So for better or worse, here's that review:

Abstract:
"replaces and obsoletes the OAuth 2.0 Authorization Framework described in
RFC 6749."
I think "replaces" is probably unnecessary here and, to be pedantic, is
arguably inaccurate because published RFCs don't ever go away or get
replaced.
Probably should also consider using the official "obsoletes" attribute
marker too for 6749 https://tools.ietf.org/html/rfc7991#section-2.45.8 and
probably also "updates"/"obsoletes" for others based on the scope of the
rest of the document (not sure how this even works with a BCP or if you can
or would want to update or obsolete a BCP) if this work proceeds. That
scope could be better described in the abstract too as discussed somewhat
in the thead
https://mailarchive.ietf.org/arch/msg/oauth/Ne4Q9erPP7SpC5051sSy6XnLDv0/
and also the 1st paragraph of
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12.
What is and isn't in scope is another larger question that I"m not even
sure how to ask. What's included vs. what's referenced? Should this doc be
incorporating bits of BCP 212 - OAuth 2.0 for Native Apps? Seems kinda
antithetical to what a BCP is supposed to be but it's also a bit hard to
tell how much was used. I mean, what happens if/when the BCP is updated?
And that kinda begs the question of if it should also incorporate parts of
or even replace the browser based apps draft? I guess that's a TBD circa
page 68. There was talk about the device grant being in scope but I'm not
seeing it (not saying it should or shouldn't be there but it was talked
about). I dunno exactly but those are some scope questions that come to
mind.
Speaking of obsoleting, I do want to ensure that existing extensions and
profiles of RFC 6749 that use legitimate extension points still present and
unchanged in OAuth 2.1 aren't inadvertently impacted by this effort. I'm
not sure how that should work in practice but want to be aware of it as/if
this work progresses.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-1
"is designed for use with HTTP ([RFC2616])."
I was momentarily proud of myself for knowing that RFC 2616 is obsolete but
then remembered that the nits tool can automate the check for other
obsolete or problematic references
https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-parecki-oauth-v2-1-01.txt
so take a look at those issues.
Probably should also check the errata of any documents this one intends to
update/obsolete or just borrowed a lot of text from to see if anything
should be applied.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-1.1
"The interaction between the authorization server and resource server is
beyond the scope of this specification."
Don't want to try and change the scope but perhaps a mention that things
like RFC 7662 Token Introspection and self-contained tokens a la JWT exist
here (or sec 1.4 or 7 or...) would be worthwhile.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-1.5
"   Steps (3), (4), (5), and (6) are outside the scope of this
   specification, as described in Section 7."
But Section 7 incorporates parts of RFC 6750 so being out of scope isn't
really true.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-1.8
Not too sure about this section in this document but seems that it should
at least reflect the fact that some things like RFC 8414  Authorization
Server Metadata do now exist.


https://tools.ietf.org/html/rfc6749?#section-1.9
All the cool drafts are doing BCP 14 [RFC2119] [RFC8174] these days.


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-2
Mentioning the existence of RFC 7591 Dynamic Client Registration here seems
appropriate. And I think it's be super useful to say that even when RFC
7591 isn't being used directly, it (and registered extensions to it
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#client-metadata)
imply a common general data model for clients that's pretty widely used and
useful even with so called static registration that "typically involve
end-user interaction with an HTML registration form."


https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-2.2
"Authorization servers SHOULD NOT allow clients to influence their
   "client_id" or "sub" value or any other claim if that can cause
   confusion with a genuine resource owner."
This text taken from draft-ietf-oauth-security-topic is out of context and
somewhere between meaningless and confusing here in this document. Removing
it or maybe something like this might be more appropriate:
  "Authorization servers SHOULD NOT allow clients to influence their

Re: [OAUTH-WG] Caution about open redirectors using the state parameter

[Neil Madden]

I think the correct defence is to validate the URL (eg check against a 
whitelist) at the point you are going to redirect to it after the OAuth flow 
completes, rather than before you begin the OAuth flow. 

But this feels like generic web app security advice rather than anything 
specific to OAuth - always validate URLs before performing a redirect.

Neil

> On 21 Apr 2020, at 20:28, George Fletcher 
>  wrote:
> 
>  +1
> 
> However, we should be careful how we prohibit it... because if the state 
> value is actually signed, having the URL there isn't a problem as the 
> attacker can not manipulate the value without breaking the signature.
> 
>> On 4/20/20 5:28 PM, Mike Jones wrote:
>> I've seen several circumstances where "clever" clients implement an open 
>> redirector by encoding a URL to redirect to in the state parameter value.  
>> Attackers can then utilize this open redirector by choosing a state value.
>> 
>> Can we please add an explicit prohibition of this practice in 
>> draft-ietf-oauth-security-topics?
>> 
>>Thanks,
>>-- Mike
>> 
>> 
>> 
>> 
>> ___
>> 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

Re: [OAUTH-WG] Caution about open redirectors using the state parameter

[George Fletcher]

+1

However, we should be careful how we prohibit it... because if the state 
value is actually signed, having the URL there isn't a problem as the 
attacker can not manipulate the value without breaking the signature.


On 4/20/20 5:28 PM, Mike Jones wrote:

I've seen several circumstances where "clever" clients implement an open 
redirector by encoding a URL to redirect to in the state parameter value.  Attackers can 
then utilize this open redirector by choosing a state value.

Can we please add an explicit prohibition of this practice in 
draft-ietf-oauth-security-topics?

Thanks,
-- Mike



___
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

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Vittorio Bertocci]

Ouch! Sorry  fixed

From: Dominick Baier 
Date: Tuesday, April 21, 2020 at 10:23
To: oauth , Rifaat Shekh-Yusef , 
Vittorio Bertocci 
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 
2.0 Access Tokens"

Oh and while we are at it - could you also fix the typo in my name? Thanks ;)

———
Dominick Baier


On 21. April 2020 at 09:43:49, Vittorio Bertocci 
(vittorio.berto...@auth0.com) wrote:
This is a great point. In my head I just considered the OIDC semantic and 
thought only of highlighting the app identity case, but you are absolutely 
right that not mentioning the user case at all is confusing. I added the 
language you suggested at the beginning of the sub definition.
Thanks!

From: Dominick Baier 
mailto:dba...@leastprivilege.com>>
Date: Monday, April 20, 2020 at 22:54
To: oauth mailto:oauth@ietf.org>>, Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail.com>>, 
"vittorio.berto...@auth0.com" 
mailto:vittorio.berto...@auth0.com>>
Subject: RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 
2.0 Access Tokens"


In case of access tokens obtained through grants where no resource owner is 
involved, such as the client credentials grant, the value of sub SHOULD 
correspond to an identifier the authorization server uses to indicate the 
client application.

Maybe I am missing something, but does it say anywhere what to explicitly do in 
the case of an access token where a resource owner is involved?

There’s some language that seems to imply that, e.g.:


as this would allow malicious

   clients to select the sub of a high privilege resource owner
I would have expected to see something stronger like above just -


In case of access tokens obtained through grants where a resource owner is 
involved, such as the authorisation code grant, the value of sub SHOULD 
correspond to the subject identifier of the resource owner.

If this spec is about interop, I think this should be at least a 
recommendation...


———
Dominick Baier


On 20. April 2020 at 09:48:51, 
vittorio.berto...@auth0.com 
(vittorio.berto...@auth0.com) wrote:
Thanks Dominick for your comments!
Inline

> All other OAuth specs make a very clear distinction between users and client.
There’s a nuance worth highlighting here: sub != user. In previous discussions 
on this topic it has been brought up that the JWT spec defines sub as 
identifying the principal that is the subject of the JWT, and that’s not 
necessarily limited to users.

However I get the potential confusion, and I am happy to add clarifying 
language if you have specific passages in the space you are particularly 
worried about: however I feel the matter is addressed upfront by the language 
in Section 2.2. in the sub entry, “In case of access tokens obtained through 
grants where no resource owner is involved, such as the client credentials 
grant, the value of sub SHOULD correspond to an identifier the authorization 
server uses to indicate the client application.“ and Section 5 has an entire 
paragraph discussing things to watch out in assigning sub values in the app 
identity case. Feel free to suggest additional language if you want to clarify 
further.

> sub has a different semantic here as in OIDC
The  spec refers to RFC7519 in the sub definition in 2.2, rather than OIDC, to 
preempt that concern and keep the original sub semantic available.

> I am not fully clear why aud is required.
Aud is there mostly because of three reasons:

• Many existing specs postulate its existence in the token. No one 
declares it as a proper MUST (apart from the BCP, but that’s partial) however I 
think its importance comes across..
-Bearer token usage RFC6750 calls it out (in threat mitigation) as the 
mechanism to prevent token redirect (and adds scope restriction as also 
important, however here we make it optional to acocut for non-delegations 
scenario).
-Resource indicators RFC8707 refers to the same section of RFC7519 as one of 
the assumptions that must hold to prevent bearer tokens misuse
-BCP225 makes aud mandatory for AS which can issue JWTs for more than one app

• Apart from Ping, for which some of its examples are without aud (but 
also without identifying scopes, given that the one I retrieved had only 
“openid”), all of the sample JWT ATs I received from vendors all featured an 
aud. I know one shoulnd’t overindex on those examples, but together with the 
above it seemed to point to something universally useful. One possible reason 
is that use of a format for the AT is correlated with topologies where AS and 
RS are separated by some boundary (network, logical, business, code factoring, 
etc) hence identifying the resource seems like a natural need. Again, not an 
iron clad law, but an indication.

• A lot of people repurpose existing libraries for the JWT AT case, and 

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Mike Jones]

This feedback is from a Microsoft engineer on the Azure Active Directory 
identity team:


  *   1
 *   Missing space at “Tokens(JWT)”
  *   2.1
 *   Use of “MUST” saying one form must be used, followed by “SHOULD” 
saying a different format should be used is a bit confusing. I get the point, 
but I had to read it several times.
 *   Missing space at “Therefore,the”
  *   2.2.1
 *   References the definitions of “acr”, “amr” and “auth_time” from OpenID 
Connect. In OpenID Connect, these explicitly refer to the end-user’s 
authentication. Does this mean these claims should only be used when the 
subject is a user? If so, then it might be good to clarify. If not (and these 
also apply for client credentials, for example), then a reference to OpenID 
Connect may not be ideal.
  *   2.2.2
 *   Use of “resource owner” suggests the resource owner is the subject of 
the token. This is not always true. In client credentials it’s not, and even in 
scenarios with a user, is it necessarily the resource owner who is 
authenticated/authorized? (Or could it be a different user who has been 
separate authorized for the requested access by the resource owner?)
  *   2.2.3.1
 *   Link to section 4.1.2 of SCIM Core is actually linking to section 
4.1.2 of this doc.
 *   States “groups”, “roles” and “entitlements” in SCIM don’t have a 
vocabulary defined, but as far as I can tell, “groups” does have a syntax 
defined in SCIM.
  *   3
 *   Missing newline in the example, before “”
  *   4
 *   States the configuration metadata is used to: “advertise to resource 
servers [and] what iss claim value to expect via the issuer metadata value”. 
This seems circular, since the configuration metadata is itself obtained by 
appending a suffix to a known (and trusted) issuer value, right?
 *   “AS” I used without having been introduced as abbreviation of 
“authorization server”.
 *   States that any JWT token with “typ” value other than “at+jwt” must be 
rejected.
*   The value “application/at+jwt” should also be accepted.
*   As written, this might be interpreted to mean there is no 
possibility of a future JWT token profile to be specified for use as a Bearer 
token (e.g. one with media type “application/example+jwt”). I believe the 
intent is to say that if the “typ” value is not “at+jwt”, it should rejected 
for this profile. (But maybe that’s already understood?)
 *   Third bullet suggests the issuer identifier is obtained through 
discovery. Discovery defines the location of the metadata to be derived from 
the issuer identifier. This circular reference is confusing.
 *   Use of singular suggests there is only one possible “aud” value that a 
resource server would accept.
 *   States the signing key must be obtained from the authorization server. 
Is this requirement necessary? (E.g. I believe Azure AD supports a resource 
server owner providing a custom signing key, in which case the RS is not 
retrieving the signing key from the AS.)
 *   I expected some reference to JWT validation steps from RFC 7519
  *   5
 *   “as this would allow malicious clients to select the sub of a high 
privilege resource owner”: the subject of the access token is not necessarily 
the resource owner (e.g. client credentials).
 *   “To preventing cross-JWT confusion”: might be good to reference 
section 2.8 of RFC 8725 to clarify what “cross-JWT confusion” is
 *   “each scope string included in the resulting JWT access token, if any, 
can be unambiguously correlated to a specific resource among the ones listed in 
the aud claim” specifies an unambiguous mapping, but section 2.1.1 of 
RFC8693 suggests a Catesian 
product of resources and scopes is possible, meaning that one scope value could 
(legitimately) map to multiple audience values. It’s unclear if the intent here 
is to avoid the ambiguity for specifying that it must not be ambiguous, or if 
there’s a slight conflict between the specs.
 *   Extra ‘n’ at “OpennID Connect’
  *   7.1.1
 *   Typo at “JTW”
 *   Missing ‘A’ at “N/”
  *   7.2
 *   Missing space at ‘”roles”,”groups”’
  *   Reference:
 *   No link to OpenID.Core
  *   All over:
 *   Missing double quotes around claim and parameter names (e.g. 2.2, 
2.2.3), which is inconsistent with other OAuth 2.0 specs, I think.


From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Wednesday, April 15, 2020 11:59 AM
To: oauth 
Subject: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 
Access Tokens"

Hi all,

This is a second working group last call for "JSON Web Token (JWT) Profile for 
OAuth 2.0 Access Tokens".

Here is the document:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06

Please send your comments to the OAuth mailing list by April 29, 2020.

Regards,
 Rifaat & Hannes

___
OAuth mailing list

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Dominick Baier]

Oh and while we are at it - could you also fix the typo in my name? Thanks
;)

———
Dominick Baier

On 21. April 2020 at 09:43:49, Vittorio Bertocci (
vittorio.berto...@auth0.com) wrote:

This is a great point. In my head I just considered the OIDC semantic and
thought only of highlighting the app identity case, but you are absolutely
right that not mentioning the user case at all is confusing. I added the
language you suggested at the beginning of the sub definition.

Thanks!



*From: *Dominick Baier 
*Date: *Monday, April 20, 2020 at 22:54
*To: *oauth , Rifaat Shekh-Yusef , "
vittorio.berto...@auth0.com" 
*Subject: *RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for
OAuth 2.0 Access Tokens"



In case of access tokens obtained through grants where no resource
owner is involved, such as the client credentials grant, the value of
sub SHOULD correspond to an identifier the authorization server uses
to indicate the client application.



Maybe I am missing something, but does it say anywhere what to explicitly
do in the case of an access token where a resource owner is involved?



There’s some language that seems to imply that, e.g.:



as this would allow malicious

   clients to select the sub of a high privilege resource owner

I would have expected to see something stronger like above just -



In case of access tokens obtained through grants where a resource
owner is involved, such as the authorisation code grant, the value of
sub SHOULD correspond to the subject identifier of the resource owner.



If this spec is about interop, I think this should be at least a
recommendation...





———

Dominick Baier



On 20. April 2020 at 09:48:51, vittorio.berto...@auth0.com (
vittorio.berto...@auth0.com) wrote:

Thanks Dominick for your comments!

Inline



*>** All other OAuth specs make a very clear distinction between users and
client.*

There’s a nuance worth highlighting here: sub != user. In previous
discussions on this topic it has been brought up that the JWT spec defines
sub as identifying the principal that is the subject of the JWT, and that’s
not necessarily limited to users.

However I get the potential confusion, and I am happy to add
clarifying language if you have specific passages in the space you are
particularly worried about: however I feel the matter is addressed
upfront by the language in Section 2.2. in the sub entry, “In case of
access tokens obtained through grants where no resource owner is
involved, such as the client credentials grant, the value of sub
SHOULD correspond to an identifier the authorization server uses to
indicate the client application.“ and Section 5 has an entire
paragraph discussing things to watch out in assigning sub values in
the app identity case. Feel free to suggest additional language if you
want to clarify further.



*> sub has a different semantic here as in OIDC*

The  spec refers to RFC7519 in the sub definition in 2.2, rather than OIDC,
to preempt that concern and keep the original sub semantic available.



*>** I am not fully clear why aud is required.*

Aud is there mostly because of three reasons:

· Many existing specs postulate its existence in the token. No one
declares it as a proper MUST (apart from the BCP, but that’s partial)
however I think its importance comes across..
-Bearer token usage RFC6750 calls it out (in threat mitigation) as the
mechanism to prevent token redirect (and adds scope restriction as also
important, however here we make it optional to acocut for non-delegations
scenario).
-Resource indicators RFC8707 refers to the same section of RFC7519 as one
of the assumptions that must hold to prevent bearer tokens misuse
-BCP225 makes aud mandatory for AS which can issue JWTs for more than one
app

· Apart from Ping, for which some of its examples are without aud
(but also without identifying scopes, given that the one I retrieved had
only “openid”), all of the sample JWT ATs I received from vendors all
featured an aud. I know one shoulnd’t overindex on those examples, but
together with the above it seemed to point to something universally useful.
One possible reason is that use of a format for the AT is correlated with
topologies where AS and RS are separated by some boundary (network,
logical, business, code factoring, etc) hence identifying the resource
seems like a natural need. Again, not an iron clad law, but an indication.

· A lot of people repurpose existing libraries for the JWT AT case,
and some people even sends id_tokens in lieu of ATs. That doesn’t mean that
we should condone any bad practices, but in tis particular case it suggests
that lots of developers already expect/can handle an audience in the JWT
used to call their API

None of those are a slam dunk argument for mandatory, but I find them
compelling enough to simplify validation and just require an aud to be
there, as opposed to introduce complications that make it conditional to
the presence of scopes or other 

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-21.txt

[Brian Campbell]

I'd agree that Vladimir's proposed wording is more meaningful/helpful.

On Mon, Apr 20, 2020 at 12:12 AM Vladimir Dzhuvinov 
wrote:

> Nat, John, thanks for updating the JAR spec. I just reviewed it, in
> particular the authz request and the security considerations sections.
> Choosing to make client_id (as top-level parameter) mandatory for all
> cases, even for those when it can be readily extracted from the JWT, makes
> the job of implementers even easier.
>
>
> I have just one comment about the last paragraph in section 5, assuming
> backward compatibility means with RFC6749 requests. Here is my proposed
> wording:
>
> The client MAY send the parameters included in the request object
> duplicated in the query parameters. For instance, this can be done
> to ensure the minimal required query parameters for an OAuth 2.0
> [RFC6749] authorization request are also present. An authorization
> server supporting this specification MUST however only use the
> parameters included in the request object.
>
>
> Vladimir
>
>
> On 19/04/2020 21:30, internet-dra...@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
> Title   : The OAuth 2.0 Authorization Framework: JWT Secured 
> Authorization Request (JAR)
> Authors : Nat Sakimura
>   John Bradley
>   Filename: draft-ietf-oauth-jwsreq-21.txt
>   Pages   : 31
>   Date: 2020-04-19
>
> Abstract:
>The authorization request in OAuth 2.0 described in RFC 6749 utilizes
>query parameter serialization, which means that Authorization Request
>parameters are encoded in the URI of the request and sent through
>user agents such as web browsers.  While it is easy to implement, it
>means that (a) the communication through the user agents are not
>integrity protected and thus the parameters can be tainted, and (b)
>the source of the communication is not authenticated.  Because of
>these weaknesses, several attacks to the protocol have now been put
>forward.
>
>This document introduces the ability to send request parameters in a
>JSON Web Token (JWT) instead, which allows the request to be signed
>with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
>(JWE) so that the integrity, source authentication and
>confidentiality property of the Authorization Request is attained.
>The request can be sent by value or by reference.
>
>
> The IETF datatracker status page for this draft 
> is:https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>
> There are also htmlized versions available 
> at:https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-21
>
> A diff from the previous version is available 
> at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-21
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP 
> at:ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Vittorio Bertocci]

This is a great point. In my head I just considered the OIDC semantic and 
thought only of highlighting the app identity case, but you are absolutely 
right that not mentioning the user case at all is confusing. I added the 
language you suggested at the beginning of the sub definition.
Thanks!

From: Dominick Baier 
Date: Monday, April 20, 2020 at 22:54
To: oauth , Rifaat Shekh-Yusef , 
"vittorio.berto...@auth0.com" 
Subject: RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 
2.0 Access Tokens"


In case of access tokens obtained through grants where no resource owner is 
involved, such as the client credentials grant, the value of sub SHOULD 
correspond to an identifier the authorization server uses to indicate the 
client application.

Maybe I am missing something, but does it say anywhere what to explicitly do in 
the case of an access token where a resource owner is involved?

There’s some language that seems to imply that, e.g.:


as this would allow malicious

   clients to select the sub of a high privilege resource owner
I would have expected to see something stronger like above just -


In case of access tokens obtained through grants where a resource owner is 
involved, such as the authorisation code grant, the value of sub SHOULD 
correspond to the subject identifier of the resource owner.

If this spec is about interop, I think this should be at least a 
recommendation...


———
Dominick Baier


On 20. April 2020 at 09:48:51, 
vittorio.berto...@auth0.com 
(vittorio.berto...@auth0.com) wrote:
Thanks Dominick for your comments!
Inline

> All other OAuth specs make a very clear distinction between users and client.
There’s a nuance worth highlighting here: sub != user. In previous discussions 
on this topic it has been brought up that the JWT spec defines sub as 
identifying the principal that is the subject of the JWT, and that’s not 
necessarily limited to users.

However I get the potential confusion, and I am happy to add clarifying 
language if you have specific passages in the space you are particularly 
worried about: however I feel the matter is addressed upfront by the language 
in Section 2.2. in the sub entry, “In case of access tokens obtained through 
grants where no resource owner is involved, such as the client credentials 
grant, the value of sub SHOULD correspond to an identifier the authorization 
server uses to indicate the client application.“ and Section 5 has an entire 
paragraph discussing things to watch out in assigning sub values in the app 
identity case. Feel free to suggest additional language if you want to clarify 
further.

> sub has a different semantic here as in OIDC
The  spec refers to RFC7519 in the sub definition in 2.2, rather than OIDC, to 
preempt that concern and keep the original sub semantic available.

> I am not fully clear why aud is required.
Aud is there mostly because of three reasons:

· Many existing specs postulate its existence in the token. No one 
declares it as a proper MUST (apart from the BCP, but that’s partial) however I 
think its importance comes across..
-Bearer token usage RFC6750 calls it out (in threat mitigation) as the 
mechanism to prevent token redirect (and adds scope restriction as also 
important, however here we make it optional to acocut for non-delegations 
scenario).
-Resource indicators RFC8707 refers to the same section of RFC7519 as one of 
the assumptions that must hold to prevent bearer tokens misuse
-BCP225 makes aud mandatory for AS which can issue JWTs for more than one app

· Apart from Ping, for which some of its examples are without aud (but 
also without identifying scopes, given that the one I retrieved had only 
“openid”), all of the sample JWT ATs I received from vendors all featured an 
aud. I know one shoulnd’t overindex on those examples, but together with the 
above it seemed to point to something universally useful. One possible reason 
is that use of a format for the AT is correlated with topologies where AS and 
RS are separated by some boundary (network, logical, business, code factoring, 
etc) hence identifying the resource seems like a natural need. Again, not an 
iron clad law, but an indication.

· A lot of people repurpose existing libraries for the JWT AT case, and 
some people even sends id_tokens in lieu of ATs. That doesn’t mean that we 
should condone any bad practices, but in tis particular case it suggests that 
lots of developers already expect/can handle an audience in the JWT used to 
call their API
None of those are a slam dunk argument for mandatory, but I find them 
compelling enough to simplify validation and just require an aud to be there, 
as opposed to introduce complications that make it conditional to the presence 
of scopes or other disambiguation. One reason I feel pretty good about that is 
that adding a default audience isn’t very hard if any of the above