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

Benjamin Kaduk <kaduk@mit.edu> Wed, 03 June 2020 04:12 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88DF3A127D for <oauth@ietfa.amsl.com>; Tue, 2 Jun 2020 21:12:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwEnGPnUikG7 for <oauth@ietfa.amsl.com>; Tue, 2 Jun 2020 21:12:47 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80AA3A127B for <oauth@ietf.org>; Tue, 2 Jun 2020 21:12:46 -0700 (PDT)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0534CdgN013989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 3 Jun 2020 00:12:41 -0400
Date: Tue, 2 Jun 2020 21:12:38 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Janak Amarasena <janakama360@gmail.com>
Cc: oauth <oauth@ietf.org>, Vittorio Bertocci <vittorio.bertocci@auth0.com>
Message-ID: <20200603041238.GR58497@mit.edu>
References: <CADNypP8t4oVUpoqOFhb-Aft-5C4Z2F9O2vBxh6QxmkHrWkN_gw@mail.gmail.com> <7cf781ef-67c9-eddd-3076-403e59e371bc@free.fr> <20200521200735.GL58497@kduck.mit.edu> <e835def4-9688-112f-eadc-f645a303fa40@free.fr> <20200530205522.GV58497@kduck.mit.edu> <CAM7dPt1gKxmZB8DdFP55JWx=WnYRFvP+_fv+pU9SJn_JnYJ4rA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAM7dPt1gKxmZB8DdFP55JWx=WnYRFvP+_fv+pU9SJn_JnYJ4rA@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/M9C_pOaOyMmmzfXc_0SHH2E0nqE>
Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2020 04:12:49 -0000

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 <kaduk@mit.edu> 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
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >