Re: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues

Justin Richer <jricher@MIT.EDU> Mon, 02 November 2015 16:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C06EA1B4988 for <>; Mon, 2 Nov 2015 08:42:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TaoeEkQ7iiM8 for <>; Mon, 2 Nov 2015 08:42:53 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A61781A039D for <>; Mon, 2 Nov 2015 08:42:52 -0800 (PST)
X-AuditID: 1209190e-f79296d00000051c-b6-5637928a01cc
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 65.72.01308.B8297365; Mon, 2 Nov 2015 11:42:51 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id tA2Ggocx017654; Mon, 2 Nov 2015 11:42:50 -0500
Received: from ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id tA2GgKop004425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Nov 2015 11:42:37 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_D5B4C35B-3EAE-4F74-8FC4-7662FD013CE1"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer <jricher@MIT.EDU>
In-Reply-To: <>
Date: Tue, 03 Nov 2015 01:42:17 +0900
Message-Id: <>
References: <>
To: Michael Ciarlillo <>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IRYrdT1+2eZB5msGsbt8WavQuZLU6+fcXm wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGU0HjrIXrAvseLe8ztsDYzfArsYOTkkBEwk 7s6eywhhi0lcuLeerYuRi0NIYDGTxPM5r6CcDYwSXS+PMIFUCQncYJK4dNgLxGYWSJDoWbuF GcTmFdCTeHXrMiuILSxgJTH3BEQ9m4CqxPyVt8BsToFAiV0NG8BqWARUJJ78fsvexcgBNEdd ov2kC8QYK4l7v86yQKwKkLgysROsXETAWOLHhQ/MEIfKSuz+/YhpAqPALCRXzEJyBURcW2LZ wtfMELamxP7u5SyY4hoSnd8msi5gZFvFKJuSW6Wbm5iZU5yarFucnJiXl1qka6yXm1mil5pS uokRFO6cknw7GL8eVDrEKMDBqMTDe8DTLEyINbGsuDL3EKMkB5OSKG9Ir3mYEF9SfkplRmJx RnxRaU5q8SFGCQ5mJRHec/1AOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZ Dg4lCV6liUCNgkWp6akVaZk5JQhpJg5OkOE8QMPLQWp4iwsSc4sz0yHypxgVpcR5pUESAiCJ jNI8uF5QOmqNdWt7xSgO9Iow7xyQKh5gKoPrfgU0mAlocPg2U5DBJYkIKakGxpqdXswL18dM e6z35B/TtU6RyeurIyf3SXJy7kv7d1DN8K558187qb4zgtaaPH7r1LYcNvubz1u0+AFnc8J3 D/ZVh7R0Zk6RyZAy4l12gb/uT4vndMWnNT859S7z7dsbLKJ9curhCUIaHzIMrkW/+KlaYXFT 8nP47KNzVW7u8H2hKrl5DZvzFiWW4oxEQy3mouJEAH9JrTYiAwAA
Archived-At: <>
Cc: "<>" <>
Subject: Re: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Nov 2015 16:42:55 -0000

Hi Michael,

Thanks for the comments. First off, the text of an RFC is fixed and cannot be changed. The spec can only be altered with a new document that obsoletes RFC7662, which would have to go through the working group process again from the very beginning.

Authentication is required but we’re open to how it happens. The introspection spec is targeted at resource servers, not clients, since a client can always just *use* the token in order to see if it’s valid or not. Why bother with the extra round trip to check if the token is good before trying it, since trying it will also tell you if the token’s good? The recovery process for a failed token is the same in either state. We initially had this written for either clients or protected resources, but that’s not how people were using it and restricting its focus helped clarify the spec immensely.

ID tokens are a slightly different case as they’re an assertion targeted at the client itself, but in those cases an ID token is really meant to be self-contained as a JWT, and generally has a short validity period. If you’re looking to introspect an old ID token to check an OIDC session status, then you might be better served implementing one of the OIDC session spec components for that purpose.

Also, we didn’t mandate a specific authentication technology. Most people are going to use either client authentication or a specific OAuth token designed for this purpose. The latter of these is technically available for public clients, but then you have the question of if you want to check the status of *that* token too. Still, I think that for any clients (including public ones) the right thing to do is just use the token and see if it works. 

To the other comment, HTTP POST is the only defined verb and we’re silent on the use of other verbs. That said, many HTTP implementation frameworks don’t differentiate between verbs for requests and so a POST with body form parameters and a GET with query parameters would come out the same. We don’t outright prohibit this behavior, but it’s off-label and there are security considerations for its use.

Hope this helps,
 — Justin

> On Nov 2, 2015, at 3:17 AM, Michael Ciarlillo <> wrote:
> Hello all,
> I have a couple of comments/issues with the RFC at <>.
> According to Section 2.1 (Introspection Request) says that "To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint..." This might make sense for token introspection requests only coming from Resource Servers, but to many implementers it makes sense to allow Clients access to the introspection endpoint since it would serve the same purpose (token validity checking, particularly for refresh tokens, but also for access tokens, or identity tokens in OpenID Connect, or possibly other token types in UMA and other specs). Unfortunately, this means that public clients should be accounted for in some way, as refresh tokens don't have an explicit requirement in the OAuth 2.0 spec that they be issued only to Confidential Clients. As such, many implementers don't feel like the Introspection spec fits well for Client consumption because of the "MUST" requirement on authentication, when public clients won't have a Client Secret to authenticate with. Further, token scanning attacks would not be mitigated for authenticated callers (be they Resource Servers or Clients).
> An example of a real-world implementer discussion talking about this topic is one I had with Kévin Chalet: <>
> We are not the only ones who see this as a problem with the spec, and there do not seem to be many concrete reasons for this endpoint ONLY being for Resource Servers themselves. Can some insight into why this is the case? Can the MUST be changed to a SHOULD with the Security Considerations section expanded to talk about the issue? If not, is there another spec or draft out there somewhere for OAuth token validity for which the intent is explicitly client consumption? Any and all feedback on this would be greatly appreciated as we develop the ASOS middleware project.
> Another (small) comment on the spec: Section 2.1 (Introspection Request) currently says that requests be HTTP POST method requests, however Section 4 (Security Considerations) mentions Authorization Servers explicitly disallowing the GET method due to server logs. What is the requirement here? POST with optional GET or explicitly only allowing POST requests?
> Sincerely,
> Michael Ciarlillo
> _______________________________________________
> OAuth mailing list