[OAUTH-WG] OAuth 2.0 Introspection RFC Issues

Michael Ciarlillo <michael.ciarlillo@gmail.com> Sun, 01 November 2015 18:17 UTC

Return-Path: <michael.ciarlillo@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id F0C1B1B8AC8 for <oauth@ietfa.amsl.com>; Sun, 1 Nov 2015 10:17:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8dUhkvN_3j2v for <oauth@ietfa.amsl.com>; Sun, 1 Nov 2015 10:17:08 -0800 (PST)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7CE61B8A6F for <oauth@ietf.org>; Sun, 1 Nov 2015 10:17:07 -0800 (PST)
Received: by qgeo38 with SMTP id o38so101434349qge.0 for <oauth@ietf.org>; Sun, 01 Nov 2015 10:17:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZK2ZejyGdi9Qi1nTveTW7EY6pY5aShJ4NQK6QPPl6eg=; b=D/r2O2aG4ZQFf6iYn1G1ln/1ePC+1XgTyQT9wJ5RnioCkuTu8iMOBz4ZaybvBVJ3yK ipxhksT6SZ8DJHMzO5E/NICzkIrs1TgJUvTp3pwEJfWpDaPdaSsLxUFuDV0DzK1mkrXm C9JSFy6b01NbalfbPNvhWpfY3u18gN+VPMtyUkqTxfqHpc4H431dI1TSTYhJPpoNBcQN qw5+6nviBIezPLiNOJ9f4D8hcDJH99cteyz1l8ssIZSt0VGUSi3n4hC019H2YmS/gm16 NhlHNPmMuX3as7ERBsOfSi7Q0JTtM39G7DVj5ShmcNhKt+VeUhY+abJdOiL0LYn22Xzp +UVg==
MIME-Version: 1.0
X-Received: by with SMTP id 72mr25736303qhr.81.1446401827065; Sun, 01 Nov 2015 10:17:07 -0800 (PST)
Received: by with HTTP; Sun, 1 Nov 2015 10:17:07 -0800 (PST)
Date: Sun, 01 Nov 2015 13:17:07 -0500
Message-ID: <CAH_M0wuMq-TANrCBPRJ7LmtRfCmQdBpnitY=0ws6h4O82GrCuA@mail.gmail.com>
From: Michael Ciarlillo <michael.ciarlillo@gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="001a113560821ad50505237eab23"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/bpYtPthEAGbPj0FQ8fEJT6c6h7U>
X-Mailman-Approved-At: Mon, 02 Nov 2015 08:05:51 -0800
Subject: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 01 Nov 2015 18:19:09 -0000

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?

Michael Ciarlillo