Re: [OAUTH-WG] Concerning OAuth introspection

Justin Richer <> Wed, 23 January 2013 15:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8DC721F86D2 for <>; Wed, 23 Jan 2013 07:19:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PMtzr0NwXM59 for <>; Wed, 23 Jan 2013 07:19:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 91EF821F86CD for <>; Wed, 23 Jan 2013 07:19:22 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id DA5B81F1D11; Wed, 23 Jan 2013 10:19:21 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG ( []) by (Postfix) with ESMTP id BDBBE1F1D05; Wed, 23 Jan 2013 10:19:21 -0500 (EST)
Received: from [] ( by IMCCAS02.MITRE.ORG ( with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 23 Jan 2013 10:19:21 -0500
Message-ID: <>
Date: Wed, 23 Jan 2013 10:19:02 -0500
From: Justin Richer <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Shiu Fun Poon <>, "" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------020802070208070702030706"
X-Originating-IP: []
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Jan 2013 15:19:23 -0000

> For the client_id, if there is no client_secret, how is that 
> information going to flow thru ?  In the oauth spec, the protocol 
> allows you to specify the client_id and secret in the payload.  So it 
> would be good for this spec to follow as closely to the oauth spec, 
> that will be great.
The idea of the introspection endpoint is to exactly mimic the OAuth2 
capabilities for client authentication as well as allowing for 
authorization based on a valid OAuth2 access token, as Section 2.1 states:

    The endpoint SHOULD also require some form of authentication to
    access this endpoint, such as the Client Authentication as described
    in OAuth 2 Core Specification
    [RFC6749] or a separate OAuth2 Access Token.

This means that if you have no client secret, you don't send one. You 
can use Basic or form parameters. If you have a client assertion, you 
use that. If you have an access token, you use that. Basically, however 
your clients normally authenticate with your AS, you can do that here. 
Or if you want to, the token that you're introspecting can be its own 
key -- a use that I haven't called out specifically in the document yet 
because I'm not fully convinced of its utility.

> And for the action/operation, separate endpoint will be one way of 
> handling it.  However are you going to dictate what the endpoint is ?  
> If not, it will make sense for the request to be self-identified.  
> That will provide the most flexibility.
Yes, the specification specifically defines a separate endpoint. From 
the introduction:

    This specification defines an Introspection Endpoint that allows the
    holder of a token to query the Authorization Server to discover the
    set of metadata for a token.

And all of section 2 is titled "Introspection Endpoint" for this reason 
as well.

If there is a way either of these points could be made more clear, 
please suggest new language for the specification and I'll incorporate it.

  -- Justin

> Regards.
> On Tue, Jan 22, 2013 at 2:00 PM, Justin Richer < 
> <>> wrote:
>     (CC'ing the working group)
>     I'm not sure what the "action/operation" flag would accomplish.
>     The idea behind having different endpoints in OAuth is that they
>     each do different kinds of things. The only "action/operation"
>     that I had envisioned for the introspection endpoint is
>     introspection itself: "I have a token, what does it mean?"
>     Note that client_id and client_secret *can* already be used at
>     this endpoint if the server supports that as part of their client
>     credentials setup. The examples use HTTP Basic with client id and
>     secret right now. Basically, the client can authenticate however
>     it wants, including any of the methods that OAuth2 allows on the
>     token endpoint. It could also authenticate with an access token.
>     At least, that's the intent of the introspection draft -- if
>     that's unclear, I'd be happy to accept suggested changes to
>     clarify this text.
>      -- Justin
>     On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
>>     Justin,
>>     This spec is looking good..
>>     One thing I would like to recommend is to add
>>     "action"/"operation" to the request.  (and potentially add
>>     client_id and client_secret)
>>     So the request will be like :
>>     token                    REQUIRED
>>     operation (wording to be determine) OPTIONAL inquire (default) |
>>     revoke ...
>>     resource_id OPTIONAL
>>     client_id OPTIONAL
>>     client_secret OPTIONAL
>>     And for the OAuth client information, it should be an optional
>>     parameter (in case it is a public client or client is
>>     authenticated with SSL mutual authentication).
>>     Please consider.
>>     ShiuFun