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

William Denniss <> Mon, 02 November 2015 23:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 98ECB1A911F for <>; Mon, 2 Nov 2015 15:58:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WSiyquEDIbbB for <>; Mon, 2 Nov 2015 15:58:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7A601A911E for <>; Mon, 2 Nov 2015 15:58:36 -0800 (PST)
Received: by qgem9 with SMTP id m9so336850qge.1 for <>; Mon, 02 Nov 2015 15:58:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=97NRWgIpJjP8X11wdXjgTvpRD2gFfi/e/TSfCTJYIUo=; b=c0D7E1qj6FP+BAZdIiV1/6R5+zOR9ZGQJUpDkUaByaL7L+wqp9nn0APq+RPuYVlqE9 2tHWBTztIuehmwF/6+8q3x4QFATrB4YzFmM4BTiu3Y6sUbYd/XqddTXiAh4nlHXxOSo9 3ab+6onAHdNS4R5DN/5C3sSEQPuq2KLt020D2hfwl1EROSafiRjSO0TF30u3GFY3U7lK TPZlHAsh4t9QqO26SXbt87tm8Exd3xJD4OCaHQlSBOeEZvuWjAMj667U9LHAhTbXyYBr sBOGyLeUh2rYPGzZEVzWczqNCWdHO8XZXa2wiHMCxriKaxqNNbG9zizuAhIBn8UxKqJy 2VGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=97NRWgIpJjP8X11wdXjgTvpRD2gFfi/e/TSfCTJYIUo=; b=RtrwIcOkaAgMbZJdJo1EaOCRCU+ljxQui3Kl3VI3jGuWolobXAoTFDMm6+Vbonu5li QFfypjodAuJKezp4LEa8z9u633kJSHgsjcNIsRdv2oMs93l0xK7Du9567CAg34A9fTZV Q0dpZnT7ixKyEFYYJ5fagKearuUvwIMJ3bB2l0YDzwr0MleireY2PbDsdRcHqKoAFvRg QMPknQO6Toracxs5HE2qehmYg3JHGlKJsv4Z2JrOA2TSDAzDrbyxMMCViVqdJWJcNN+y FaAvHpGpBZmRhmfJQPlXPbJ6xPyFrdTMZvBNiJTMTCtJz/q8wa43vp2Fd8DvMl7pSNvP 4CxA==
X-Gm-Message-State: ALoCoQl58+gwbCYz9APP011B86z2vh+SoBoEUgpeyoIJek6yClpD9jzUf6w/gh80k+aUSr+51GoR
X-Received: by with SMTP id d11mr33585752qge.83.1446508715972; Mon, 02 Nov 2015 15:58:35 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: William Denniss <>
Date: Mon, 02 Nov 2015 23:58:25 +0000
Message-ID: <>
To: Justin Richer <>, Michael Ciarlillo <>
Content-Type: multipart/alternative; boundary="001a113958c82e5ddf0523978ea1"
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 23:58:39 -0000

We had a debate on that MUST at the last IETF, but the spec was too far
along to change. The workaround is to treat the token you are introspecting
as the authentication. With that workaround, the spec is quite usable for
non-confidential clients, even if resource servers were the primary target.

Google currently runs an introspection endpoint of sorts for clients, named
"tokeninfo", and the latest version (v3) is close to the spec (coincidence
- it's a good design pattern). Aimed mostly at debugging use-cases or if
you don't have a JWT decoding library handy.
On Tue, Nov 3, 2015 at 1:43 AM Justin Richer <> wrote:

> 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
> _______________________________________________
> OAuth mailing list