Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04

Thomas Broyer <> Thu, 24 October 2013 00:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAE1111E829A for <>; Wed, 23 Oct 2013 17:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y4p86sd8QaKF for <>; Wed, 23 Oct 2013 17:27:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c01::230]) by (Postfix) with ESMTP id 32A8211E82A4 for <>; Wed, 23 Oct 2013 17:27:53 -0700 (PDT)
Received: by with SMTP id jx11so873207veb.21 for <>; Wed, 23 Oct 2013 17:27:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=esoUN++Cwfs6bMZyanjBGRaEOwzTQ8jnQQVGejfxdnY=; b=IXc7f4bbqhS2PCfJNPtS7nE46603NrZgLtwb62uzgUCH98unoCTaIkvm0PlY+cho3P UcifCPEfV9ebgPpGEUO+bjoIiyNbWGdZRFVNYw/+phrKVCPVfjSB3OiYuJsJYzmJp1ev ZtxL6sBLk2mPPRTAhRlnDiv8XpjAFcaipdcZYHar5jLo5yYC/jTYootBgP9HKdCQAKZG JA69087RNSqObkyo9QKypujRN1vEtqcdBg6GciSbpuNWZJKyWs7wL4JGj4fal6Hcnpwb GJ4esJjYsY2JGkEmxwMBiYsIcy6lty4tI/9+7PqGuB0Ol6SdTHmsZibf9vj9zd/N6VpN DN7Q==
X-Received: by with SMTP id qd7mr2939026veb.1.1382574473297; Wed, 23 Oct 2013 17:27:53 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 23 Oct 2013 17:27:33 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Thomas Broyer <>
Date: Thu, 24 Oct 2013 02:27:33 +0200
Message-ID: <>
To: "Richer, Justin P." <>
Content-Type: multipart/alternative; boundary=047d7b5d45d05b47c504e971b477
Cc: "<>" <>
Subject: Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04
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: Thu, 24 Oct 2013 00:27:57 -0000

On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P. <>wrote;wrote:

>  Hi Thomas,
>  You're right in that the introspection process is about getting meta
> data about a particular token by making an authenticated call. It does
> reveal a lot of information about the token -- because that's exactly the
> point of the protocol. :)
>  If the PR is compromised, then the attacker would be able to do anything
> the PR can do, including reusing any tokens handed to the PR (assuming
> they're bearer tokens).

Yes, this is the problem with bearer tokens. Is there any spec for 'proof
tokens' besides http-mac?
As a mean of mitigating the issue, I was thinking about delivering a
refresh_token and asking Clients to generate (ask the AS) different access
tokens for each PR (or "resource set"). That would of course solve the
issue with introspection giving too much information (to my taste), but
puts burden on Client implementors, with no guarantee that they'll actually
do it. AFAICT, only a 'proof token' would really solve the issue; it's in
our backlog.

> This is true without doing introspection at all, since you can just steal
> and start broadcasting the token.

But then the AS could revoke the access token when it detects a high rate
of validation/introspection requests from many different PRs, particularly
many such requests in error!
Giving the compromised victim the list of scopes for the token would
severely limits the number of errors and it would be much harder to detect
such compromised entities.

Also, if the PR is compromised, all the data protected at that PR is also
> compromised, so you've got other problems too.

That's a problem between the PR and the ROs then, unrelated to the AS or
even Clients.
It becomes a problem with the whole system when compromising one entity
(other than the AS) gives access to personal data in others.

>  The "resource_id" parameter is meant to be a service-specific hint that
> the PR can hand to the AS to give context to the transaction. You could
> easily use this field to pass along the list of scopes that you mention
> below.

I had just skimmed through resource-reg and didn't remember the "resource
set" concept. Now that I re-read it, I better understand what that
resource_id can be.

> You can have your AS return no information other than the "valid" field in
> the response and leave out the scopes, subject, client id, and everything
> else. All those fields are optional. However, in practice we've found it
> very helpful to reveal to the PR which scopes and audiences that a token
> was issued for so that the PR can use that information to make
> authorization decisions.

But aren't authorization decisions the responsibility of the AS?
If the PR sent the scopes (or resource_id, but that would closely couple
the protocol with resource-reg, which I don't think is desirable) to the
AS, then the PR could authorize access based only on a yes/no response (and
the "no" response would give information about the "why", to be sent
directly to the Client)

> But if all you're after is answering the question "is this token valid"
> and you don't want any other information, your AS is fully allowed to do
> answer just that question.

As I said, I do need "more information", or rather, a more "contextual"

I think I'll just go with my custom protocol for now. Thanks for your