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

[Janak Amarasena <[e-mail]>]

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 <[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
>