Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Nat Sakimura <> Wed, 24 February 2016 16:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BFE921A8AAD for <>; Wed, 24 Feb 2016 08:12:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3m8FZJiQoyi9 for <>; Wed, 24 Feb 2016 08:12:53 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 662691A88AF for <>; Wed, 24 Feb 2016 08:12:53 -0800 (PST)
Received: by with SMTP id b35so17389076qge.0 for <>; Wed, 24 Feb 2016 08:12:53 -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=np+IHaxTlyNpmuU+IUoXuOeEUqYA9FRRitYFYUGDGtw=; b=x+ftdRShAx4hTfsonCAlIn6t1I3WljP9+Zf2fFb7A/7yc5Y5kQ3tyspaEmH6LSSx2y +jr01ihY8z8JDdRRA/O+gZuuXpcX6WZus0PmveWanfpTnkQEr9Dca4+/3hWtNEm92I9E FD4IvjqqW54aoUVRr81tAyaGsKClF3t0dXqHZKwHu0I+jBtH4ptUXDplEsBPVzkbCPf5 Diaw5XLvvUch9LiTvdtTAlPEXwKyfhsN5L8ImJdpXlxjA+qfkJH0TLexzvdUsmRDs6va N7ixJkV6cln7ZMwtpMjPQFRtEobQOZtGyJrPlmjmLuZTVrXJXoDIfuVVEKFSLCBkoSzI lPaQ==
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=np+IHaxTlyNpmuU+IUoXuOeEUqYA9FRRitYFYUGDGtw=; b=bc/2/NyhyWUTPE1/i25sqIKw30+Y6cI6yQyYbzuu9FHceMGiJYYErwbV47TuVMumOn gsJM/Lok5VUxSzxEzAJlH6kzUM3HKkOZ3Mbx0WVggBv/emAHDNP+0fEU7M8zNR83dmDn epWnb1hAT6EKzQaDAtUMsbsbpNIxDkc42fEPCFm2Fs6DEdfOldOI4QS77udVVI45tjYg /qpTbVhkotlmmvk5DLxaJ0jnK6Y3JLS1vbW4uNGcUgh5pR54wXuqwUQw6JVTIsnfSORQ lHht7Co65DEcssXc4GPTpYXQe/QVHAJf8bU4ONMNp+nxdm3qZVzujbcjD7NUSm36HTp7 nSsA==
X-Gm-Message-State: AG10YOQB6eSWId9w031K+6WTk6adh9/vLXURBEMN/40pH/nFOpyenhl0X2iftwn8WSmJZbfqesXcUdkloFc88g==
X-Received: by with SMTP id v132mr52633510qhc.0.1456330372481; Wed, 24 Feb 2016 08:12:52 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Nat Sakimura <>
Date: Wed, 24 Feb 2016 16:12:41 +0000
Message-ID: <>
To: Phil Hunt <>
Content-Type: multipart/alternative; boundary="001a113a99d0870cd0052c8656eb"
Archived-At: <>
Cc: "<>" <>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
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: Wed, 24 Feb 2016 16:12:56 -0000

Hi Phil,

Are you suggesting that the AS metadata should include the RS URIs?
Currently, it does not, but it can be done, I guess.

The way oauth-meta works is that

1. RS tells the client where the AS is.
2. AS tells the client which RS endpoints the token can be used.

Even if there is a bad AS with a valid certs that proxies to the good RS,
the client will not send the token there as the authz server will say that
is not the place the client may want to send the token to.


2016年2月24日(水) 23:59 Phil Hunt <>:

> Nat,
> I’m not sure that having the resource server tell the client where its
> authorization server is secure by itself. The relationship between the
> Authorization Server and the Resource server need to be bound together in
> one of the discovery endpoints (the resource and/or the oauth service
> discovery).
> If a client discovers a fake resource server that is proxying for a real
> resource server the current discovery spec will not lead the client to
> understand it has the wrong resource server. Rather the fake resource
> service will just have a fake discovery service. The hacker can now
> intercept resource payload as well as tokens because they were able to
> convince the client to use the legit authorization service but use the
> token against the hackers proxy.
> The OAuth Discovery service needs to confirm to the client that the server
> is able to issue tokens for a stated resource endpoint.
> This not only works in normal OAuth but should add security even to UMA
> situations.
> Phil
> @independentid
> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <> wrote:
> Hi Thomas,
> inline:
> 2016年2月22日(月) 18:44 Thomas Broyer <>:
>> Couldn't the document only describe the metadata?
>> I quite like the idea of draft-sakimura-oauth-meta if you really want to
>> do discovery, and leave it open to implementers / to other specs to define
>> a .well-known URL for "auto-configuration".
>> The metadata described here would then either be used as-is, at any URL,
>> returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for
>> other metadata specs (like OpenID Connect).
> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of
>> WWW-Authenticate response header, you have everything you need to proceed
> Yup. That's one of the requirements to be RESTful, is it not?
> In OAuth's case, the resource and the authorization server are usually
> tightly coupled. (Otherwise, you need another specs like UMA.)
> So, the resource server should be able to tell either the location of the
> authz endpoint. In some trusted environment, the resource may as well
> return the location of the authz server configuration data. In these cases,
> you do not have to decide on what .well-known uri as you say. This frees up
> developers from configuration file location collisions etc. We should
> strive not to pollute the uri space as much as possible.
>> (well, except if there are several ASs each with different scopes; sounds
>> like an edge-case to me though; maybe RFC6750 should instead be updated
>> with such a parameter such that an RS could return several
>> WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
> Yeah, I guess it is an edge case. I would rather like to see these authz
> servers to develop a trust framework under which they can agree on a single
> set of common scope parameter values.
> Cheers,
> Nat
>> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <> wrote:
>>> The newly-trimmed OAuth Discovery document is helpful and moving in the
>>> right direction. It does, however, still have too many vestiges of its
>>> OpenID Connect origins. One issue in particular still really bothers me:
>>> the use of “/.well-known/openid-configuration” in the discovery portion. Is
>>> this an OAuth discovery document, or an OpenID Connect one? There is
>>> absolutely no compelling reason to tie the URL to the OIDC discovery
>>> mechanism.
>>> I propose that we use “/.well-known/oauth-authorization-server” as the
>>> default discovery location, and state that the document MAY also be
>>> reachable from “/.well-known/openid-configuration” if the server also
>>> provides OpenID Connect on the same domain. Other applications SHOULD use
>>> the same parameter names to describe OAuth endpoints and functions inside
>>> their service-specific discovery document.
>>>  — Justin
>>> _______________________________________________
>>> OAuth mailing list
>> _______________________________________________
>> OAuth mailing list
> _______________________________________________
> OAuth mailing list