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

[Benjamin Kaduk <[e-mail]>]

On Mon, Jun 01, 2020 at 10:06:22PM +0530, Janak Amarasena wrote:
> 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".

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

-Ben

> 
> 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 <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >