Re: [OAUTH-WG] can a resource server provide indications about expected access tokens?

Justin Richer <jricher@mit.edu> Mon, 13 December 2021 16:38 UTC

Return-Path: <jricher@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 665D03A089C for <oauth@ietfa.amsl.com>; Mon, 13 Dec 2021 08:38:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 m6qtYjF3w-XN for <oauth@ietfa.amsl.com>; Mon, 13 Dec 2021 08:37:57 -0800 (PST)
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 50CD73A0890 for <oauth@ietf.org>; Mon, 13 Dec 2021 08:37:57 -0800 (PST)
Received: from smtpclient.apple (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1BDGbpt7014569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Dec 2021 11:37:52 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <CE063C3C-6992-4450-8153-0778C143C7A5@aueb.gr>
Date: Mon, 13 Dec 2021 11:37:51 -0500
Cc: oauth <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <22638B6D-921C-49D6-87A4-378F3D0DD500@mit.edu>
References: <CE063C3C-6992-4450-8153-0778C143C7A5@aueb.gr>
To: Nikos Fotiou <fotiou@aueb.gr>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/0MqDbr-Xrv1-nGzkfWJxOJpvXsI>
Subject: Re: [OAUTH-WG] can a resource server provide indications about expected 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: Mon, 13 Dec 2021 16:38:01 -0000

Hi Nikos,

If you mean indicate to the client, then in my view, no — not directly in a delegation protocol like OAuth, at least. The format of the token, and its contents, are abstracted away. As has been mentioned in the thread already, you can return a “scope” and other parameters to the client to indicate what it should ask for, as well as “resource” or even “authorization_details” to use RAR structures. However, there’s an important point that I see so many engineers trip over:


- Scope, resource, authorization_details (RAR), audience, etc: parameters that the client uses to describe what it wants in a request. Let’s call this the “request set”.
- iss, sub, claims, attributes, etc: items inside a JWT access token (when you use that format) to tell an RS what the token’s good for. Let’s call this the “access set”.


The client and AS communicate using the “request set”, while the AS and RS communicate in the “access set”. It’s the job of the AS — literally the primary function of the role of AS — is to translate the “request set” into an artifact, the access token, that can be interpreted in the “access set”. The access token is the artifact that provides that abstraction to the client, and the AS is the mechanism through which a client’s understanding of what it’s asking for gets translated to what the RS actually understands. 

What gets confusing is that sometimes these are the same in practice — you can use “scope” in both places as an abstraction in the access token itself. I’ve seen that work many times. But when you do that it does seem like the client is saying “put the following things inside the access token”, when what’s really happening is the client is saying “I want access to the following things” and the AS is taking that list and saying “that means these other things are what go in the access token”.

The entire purpose of a delegation protocol is that translation from “request set” to “access set” semantics. Trying to skip that gets you out of delegation protocol territory pretty quickly.

 — Justin



> On Dec 11, 2021, at 5:35 AM, Nikos Fotiou <fotiou@aueb.gr> wrote:
> 
> Hi,
> 
> I have a use case where a resource server is protected  and can only be accessed if a JWT is presented. Is there any way for the server to "indicate" the "expected" format of the JWT. For example,  respond to unauthorized requests with something that would be translated into "I expect tokens form iss X with claims [A,B,C]"
> 
> Best,
> Nikos
> 
> --
> Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
> Researcher - Mobile Multimedia Laboratory
> Athens University of Economics and Business
> https://mm.aueb.gr
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth