Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

From: Janak Amarasena <[email-masked]>
Date: Mon, 1 Jun 2020 22:06:22 +0530

Hi all,

My apologies, if this was already discussed.

In section *4*. Validating JWT Access Tokens
<https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07#section-4> it
is stated;

The resource server MUST handle errors as described in section 3.1 of
   [RFC6750] <https://tools.ietf.org/html/rfc6750#section-3.1>.  In
particular, in case of any failure in the validation
   checks listed above the *authorization server* response MUST include
   the error code "invalid_token".

Should this be;

... above the *resource server* response MUST include the error code
"invalid_token".

If that is not the case, which kind of scenarios would occur for an AS to
respond with the error code "invalid_token"?

Best Regards,
Janak Amarasena

On Sun, May 31, 2020 at 2:25 AM Benjamin Kaduk <[email-masked]> wrote:

> On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote:
> > Hi Benjamin,
> > > On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote:
> > >> Since then, I questioned myself how a client would be able to request
> an
> > >> access token that would be
> > >> *strictly compliant with this Profile*.
> > > I don't understand why this is an interesting question to ask.  The
> access
> > > token and interpretation thereof is (AIUI) generally seen as an
> internal
> > > matter between AS and RS, with the client having no need to care about
> the
> > > specifics.
> >
> > This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not
> > _*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens.
>
> Sure.  But (in my understanding), in common usage, the contents and
> interpretation of the access token is set by common agreement between AS
> and RS, with the client serving only as a "dumb" channel for transporting
> the token.  That is, we're providing a token format that an RS and AS can
> agree to use, most likely for all tokens issued by the AS for that RS.  I
> don't know of any existing mechanisms, or desire for such mechanisms by
> deployments, for using a different token format for different tokens issued
> by a given AS for a given RS.  Attempting to have the client provide input
> that would affect such a mechanism seems like complexity with no market
> demand; a "solution in search of a problem" as it were.  Is there some
> pent-up demand among OAuth deployments that I'm not aware of?  I freely
> admit to not being very on top of the broad spectrum of what's deployed...
>
> > 1) A client may wish to obtain an Access Token that corresponds to this
> > Profile because, for example,
> > this document mandates the "sub" claim to be present". Hence, the
> > content of the Access Token is not
> > totally "/an internal matter between AS and RS/".
> >
> > However, I have not understood how a client could request an Access
> > Token that corresponds to *_this_***Profile,
> > since there is no mandatory parameter in the request (both the "scope"
> > parameter and the "resource" parameter are optional).
> >
> > In the future, we could define _*another*_**Profile. Hence, there is the
> > same question:  How could a client request an Access Token
> > that corresponds to *_that other_***Profile ?
> >
> > 2) When getting a JWT,  how can the client make sure that the access
> > token it got is compliant with this Profile ?
> >
> > RFC 8725 states in section 3.11 :
> >
> >     3.11. Use Explicit Typing
> >     Sometimes, one kind of JWT can be confused for another. If a
> >     particular kind of JWT is subject to such confusion,
> >     that JWT can include an explicit JWT type value, and the validation
> >     rules can specify checking the type (...).
> >     Explicit JWT typing is accomplished by using the "typ" Header
> >     Parameter.
> >
> > Wouldn't be wise to include an explicit JWT type value for JWTs
> > conformant to this Profile ?
>
> In the model where the client is a "dumb" communications channel, this
> question does not seem interesting.  But the related question of "how can
> the RS make sure that the access token it got was generated according to
> this profile?" does seem interesting, and seems like it would benefit from
> the same proposed solution.
>
> > This relates to an email posted by Dominick Baier under the topic "JAR:
> > JWT typ" on May 19 :
> >
> >     This has been brought up before - but no response.
> >
> >     Either I can’t find it - or it is missing. But is the setting the
> >     JWT typ explicitly mentioned somewhere?
>
> It is fairly likely that I will remember to ask about explicit "typ" usage
> if I'm still on the IESG when this document gets there: I think I've been
> making a habit of doing so.
>
> Thanks,
>
> Ben
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Denis <[email-masked]>
Date: Tue, 2 Jun 2020 10:20:36 +0200

Hi Benjamin,

Responses are between the lines.

>>>> Since then, I questioned myself how a client would be able to 
>>>> request an access token that would be *strictly compliant with this 
>>>> Profile*.
>>> access token and interpretation thereof is (AIUI) generally seen as 
>>> an internal matter between AS and RS, with the client having no need 
>>> to care about the specifics.
> interpretation of the access token is set by common agreement between 
> AS and RS, with the client serving only as a "dumb" channel for 
> transporting the token. That is, we're providing a token format that 
> an RS and AS can agree to use, most likely for all tokens issued by 
> the AS for that RS. I don't know of any existing mechanisms, or desire 
> for such mechanisms by deployments, for using a different token format 
> for different tokens issued by a given AS for a given RS.

Since this document is *_a_* Profile for OAuth 2.0 Access Tokens, it 
means that potentially other Profiles could be defined in the future.
In the request, there is no parameter for a client to indicate that it 
wants a JWT conformant to _this_ profile and no parameter either
in the response to indicate to the client that it got a JWT that is 
conformant to _this_ profile.

The processing mandated in the document of a request made by a client to 
an AS only applies for a request conformant to this profile
which may or may not include a scope parameter and which may or may not 
include a "resource" parameter (and, if it does not, shall
include an "aud" claim). Currently, it is not possible to make a 
difference between a JWT request or response conformant to this profile
and other JWT requests or responses.

> Attempting to have the client provide input that would affect such a 
> mechanism seems like complexity with no market demand; a "solution in 
> search of a problem" as it were. Is there some pent-up demand among 
> OAuth deployments that I'm not aware of? I freely admit to not being 
> very on top of the broad spectrum of what's deployed...
>> 1) A client may wish to obtain an Access Token that corresponds to 
>> this Profile because, for example, this document mandates the "sub" 
>> claim to be present". Hence, the content of the Access Token is not 
>> totally "/an internal matter between AS and RS/". However, I have not 
>> understood how a client could request an Access Token that 
>> corresponds to *_this_***Profile, since there is no mandatory 
>> parameter in the request (both the "scope" parameter and the 
>> "resource" parameter are optional). In the future, we could define 
>> _*another*_**Profile. Hence, there is the same question:  How could a 
>> client request an Access Token that corresponds to *_that 
>> other_***Profile ? 2) When getting a JWT,  how can the client make 
>> sure that the access token it got is compliant with this Profile ? 
>> RFC 8725 states in section 3.11 : 3.11. Use Explicit Typing 
>> particular kind of JWT is subject to such confusion, that JWT can 
>> include an explicit JWT type value, and the validation rules can 
>> specify checking the type (...). Explicit JWT typing is accomplished 
>> by using the "typ" Header Parameter. Wouldn't be wise to include an 
>> explicit JWT type value for JWTs conformant to this Profile ?
> question does not seem interesting. But the related question of "how 
> can the RS make sure that the access token it got was generated 
> according to this profile?" does seem interesting, and seems like it 
> would benefit from the same proposed solution.

An explicit JWT type value added both in the JWT request and in the JWT 
response would solve this problem.

>> This relates to an email posted by Dominick Baier under the topic 
>> "JAR: JWT typ" on May 19 : This has been brought up before - but no 
>> response. Either I can’t find it - or it is missing. But is the 
>> setting the JWT typ explicitly mentioned somewhere?
> It is fairly likely that I will remember to ask about explicit "typ" 
> usage if I'm still on the IESG when this document gets there: I think 
> I've been making a habit of doing so.

Once again, an explicit "typ" sould be considered for both the JWT 
request and the JWT response. This implies that the client "MUST" be 
able to inspect the content of the access token.

Denis

> Thanks, Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 2 Jun 2020 21:12:38 -0700

> ... above the *resource server* response MUST include the error code

It does look like it should be the resource server there, yes.
Good catch, and thanks for mentioning it!

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 2 Jun 2020 21:23:24 -0700

Hi Denis,

> conformant to _this_ profile.

I don't think my point came through clearly.  Right now, the AS and RS have
to negotiate by some out-of-band means what token format and details to use
for tokens issued by AS with RS in audience, and there is not a
"well-known" description of how to use JWT to do so.  The goal of this
document is to simplify the out-of-band negotiation between AS and RS, so
they can just say "use RFC NNNN" instead of having to specify a lot of
details individually.  Nowhere does the client come into the current
negotiation of what token format to use, and the act of specifying a
profile of JWT for this usage does not create a requirement for the client
to be included in the negotiation.

Now, whether or not to include the client in this negotiation (and whether
or not to make the choice of token format finer-grained) may be a topic
worth discussion in its own right, but that discussion is untethered from
specifying a profile of JWT to simplify AS/RS negotiations.

> and other JWT requests or responses.

I don't see where this document places constraints on a "conformant
request" made by a client; could you point that out to me?

(FWIW, the section heading for section 3 seems needlessly confusing, as the
contents of the section do not seem to say anything about specifically
requesting a JWT token.  I can see how this heading might cause some
confusion.)

> response would solve this problem.

An explicit JWT type is a solution to the problme I'm interested in, yes.
Though I don't know if that's what you mean by "this problem".

> able to inspect the content of the access token.

As above, I do not see how the client currently has input into the token
type/format agreed upon by the AS/RS out-of-band, so I dispute both the
premise and the supposed conclusion.

-Ben

---

From: Denis <[email-masked]>
Date: Wed, 3 Jun 2020 18:13:03 +0200

Hi Benjamin,

My responses are between the lines.

> details individually.

At this time, it is still unknown how a client can request a JWT 
conformant to /this/ profile,
i.e. I have not identified in the protocol a request parameter saying 
"use RFC NNNN".

> Nowhere does the client come into the current negotiation of what token format to use,
> and the act of specifying a profile of JWT for this usage does not create a requirement
> for the client to be included in the negotiation.

It is not a "negotiation" where one party proposes a set of choices and 
the other party selects one of these choices,
it is supposed to be a protocol where the client is saying "please 
provide me a token compliant with RFC NNNN".
Unfortunately, the current protocol description does not allow to do so.

> specifying a profile of JWT to simplify AS/RS negotiations.

Agreed. It is not a matter for this working draft which may be discussed 
using a separate thread.

> requesting a JWT token.  I can see how this heading might cause some

This is the core of the discussion: the current protocol description 
does not
allow a client to say: "Please provide me a token compliant with RFC NNNN".

> Though I don't know if that's what you mean by "this problem".

  The problem that still needs to be solved is a way for a client to be 
able to state:
"Please provide me a token compliant with RFC NNNN".

> premise and the supposed conclusion.

Since the token format negotiation is out-of-band (i.e. it is not 
specified in the current RFCs
or in drafts in preparation) all assumptions can be made of the way(s) a 
RS makes available
the token formats it supports. Without knowing anything about which 
token formats are
being supported, the client may attempt to ask: "Please provide me a 
token compliant with
RFC NNNN". This will fail or succeed. So the client does not need to 
have any knowledge
about the token type/format agreed upon by the AS/RS out-of-band.

Denis