Re: [OAUTH-WG] aud in JWT Response for OAuth Token Introspection
Justin Richer <jricher@mit.edu> Wed, 15 May 2019 20:54 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 EA5AD12010F for <oauth@ietfa.amsl.com>; Wed, 15 May 2019 13:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 Kkknf0eWqWUs for <oauth@ietfa.amsl.com>; Wed, 15 May 2019 13:54:46 -0700 (PDT)
Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (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 9CA25120106 for <oauth@ietf.org>; Wed, 15 May 2019 13:54:45 -0700 (PDT)
Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id x4FKsTgt019064; Wed, 15 May 2019 16:54:45 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 15 May 2019 16:54:31 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 15 May 2019 16:54:34 -0400
Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Wed, 15 May 2019 16:54:34 -0400
From: Justin Richer <jricher@mit.edu>
To: Takahiko Kawasaki <taka@authlete.com>
CC: oauth <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] aud in JWT Response for OAuth Token Introspection
Thread-Index: AQHVBKI2qWhovuHGfke9RwvZb6FCqaZs+pWA
Date: Wed, 15 May 2019 20:54:33 +0000
Message-ID: <FB651576-2A01-4E73-800F-D6AC221BCB6A@mit.edu>
References: <CAHdPCmPFJUpJ5Ko4Hdt-SFL8vgqwEJQSd+nCN7ot9bqTX2Am=w@mail.gmail.com>
In-Reply-To: <CAHdPCmPFJUpJ5Ko4Hdt-SFL8vgqwEJQSd+nCN7ot9bqTX2Am=w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [71.174.62.56]
Content-Type: multipart/alternative; boundary="_000_FB6515762A014E73800FD6AC221BCB6Amitedu_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/21u0ImzqaZN8v_7UC-CB1sXiHE8>
Subject: Re: [OAUTH-WG] aud in JWT Response for OAuth Token Introspection
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, 15 May 2019 20:54:55 -0000
This is not an easy question to answer, as resource servers in OAuth have never really had a strong identity (or identifier) within the OAuth ecosystem. The Resource Identifiers draft [1] tries to address this somewhat. In practice, many resource servers are registered and stored as “clients” at an AS so that the AS can re-use authentication code paths and storage systems. I know that in several large deployments that I’ve worked on, resources are stored as clients with empty “grant_types” and “response_types” arrays, and with a flag set to allow them to call the introspection endpoint. Otherwise they are all “client” objects and therefore get ‘client_id’ fields assigned to them, which would be what the “aud” would be in this case, most likely. However, unlike clients, resource servers arguably always have at least one URL associated with them. The real problem comes from the fact that the “resource” isn’t easily defined by a single URL. — Justin [1] https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators On May 7, 2019, at 2:57 AM, Takahiko Kawasaki <taka@authlete.com<mailto:taka@authlete.com>> wrote: Hello, I have a question regarding "JWT Response for OAuth Token Introspection" (draft-02). https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/?include_text=1 How to determine the value of "aud" in the response JWT? The example payload uses "https://protected.example.net/resource" as the value of "aud". The example value implies that it represents the identifier of the target resource or the resource server, but how does an authorization server implementation know the identifier? I'm sorry if this has already been discussed. To be honest, I fear that some inconsistencies might occur in future by treating resource servers as clients. If I had to write the specification, I would start from defining "resource server metadata" (e.g. expired draft: https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/) and devising a way to register resource servers into an authorization server and issue resource server credentials (e.g. rs_id and rs_secret, RS JWK Set, etc.) in order to treat resource servers and clients as different entities explicitly. I hope that discussion for distinguishing "resource server authentication" from "client authentication" will be initiated sometime in future. Best Regards, Takahiko Kawasaki Authlete, Inc. _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] aud in JWT Response for OAuth Token In… Takahiko Kawasaki
- Re: [OAUTH-WG] aud in JWT Response for OAuth Toke… Justin Richer