Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Mike Jones <> Wed, 24 February 2016 23:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 047431A8900 for <>; Wed, 24 Feb 2016 15:28:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.379
X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k6zxrXFHmhhY for <>; Wed, 24 Feb 2016 15:28:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CCBFC1A88F9 for <>; Wed, 24 Feb 2016 15:28:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fg/l9jKT8s3PE61a5SDq8+oPFLNygdzmccpTdToGJgE=; b=E9NfggLx310fQUUrB3irW5wPMBzP/tFbAGmtOJFOWNDX/fp9Irm57UcEp1m0+YII6wMOhkrtK3LXePgY99VrL4KxVlGIUO+OdFv9z+ZOAlnRAZrYVr/NlMzIoJR8QVIfs5xaIBVc95EfGEQQKm/cyxReEH7VrkOM8mOlf8xPLCQ=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.409.15; Wed, 24 Feb 2016 23:28:26 +0000
Received: from ([]) by ([]) with mapi id 15.01.0409.024; Wed, 24 Feb 2016 23:28:26 +0000
From: Mike Jones <>
To: "Phil Hunt (IDM)" <>
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Date: Wed, 24 Feb 2016 23:28:26 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: [2001:4898:80e8:3::650]
x-ms-office365-filtering-correlation-id: 2209e89a-87dd-483b-7229-08d33d723248
x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:VnDwziDG2n8vfYoC+72YjUqpWzWMt0yxIhX/u441mdFaUQT840SkYGdN5F6OXBjXt2ZhDp/VyLUCbiTzOXpPO5NztWCzKpT/ZlF7syjUE+OhfGB1O2gJJFX7cPgZMEqZ9MPXWdYqlwIIc9abmPJM/A==; 24:WUJ7Py8xgWrGATnLvJtvd5NmzZaDE3olO+7pHDLZ4rC97rA0dQAHQOjx2Ck0FEaXK6TuZdDuBk8i3KBlm1/BgfHg/faudcaXWqAkcFhOR0M=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444;
x-forefront-prvs: 08626BE3A5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51914003)(377454003)(24454002)(106116001)(87936001)(99286002)(19300405004)(76576001)(76176999)(92566002)(5001960100002)(10090500001)(19617315012)(15395725005)(86362001)(16236675004)(54356999)(50986999)(189998001)(110136002)(86612001)(5002640100001)(1220700001)(3280700002)(19625215002)(33656002)(586003)(19580405001)(19580395003)(74316001)(3660700001)(93886004)(1096002)(102836003)(790700001)(5004730100002)(6116002)(19609705001)(10290500002)(5005710100001)(40100003)(10400500002)(122556002)(8990500004)(11100500001)(2906002)(2950100001)(2900100001)(5008740100001)(77096005)(4326007)(15975445007)(5003600100002)(3900700001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442C4E813E7ADFED795526BF5A50BY2PR03MB442namprd_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2016 23:28:26.6984 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444
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 23:28:35 -0000

The UserInfo Endpoint path isn’t fixed and so has to be discovered.

I agree that for some OAuth profiles, one or more resource servers will have to be discovered starting from the authorization server.  Working group members have also described wanting to discover authorization servers starting from resource servers.  There isn’t a standard practice for any of this, which is why it’s intentionally left out of the current specification.

Once the IANA OAuth Discovery Metadata Registry has been established, which will happen after the current specification has been approved, it will be easy for subsequent specifications to document existing practice for different OAuth profiles and register discovery metadata values supporting them.  Some of those values will likely define ways to discover resource servers, when applicable.

But first, we need to finish the existing spec, so that the registry enabling these extensions gets established in the first place.

                                                                -- Mike

From: Phil Hunt (IDM) []
Sent: Wednesday, February 24, 2016 2:13 PM
To: Mike Jones <>
Cc: <> <>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Yup. And because there many relations the client mist be able to discover it. The client does not know if the res server is legit.

The userinfo is always fix and so u dont need discovery.


On Feb 24, 2016, at 14:05, Mike Jones <<>> wrote:
In OpenID Connect, there’s a resource server called the UserInfo Endpoint that returns claims about the authenticated user as a JSON data structure.  Its location is published in OpenID Connect discovery metadata as the “userinfo_endpoint” metadata value, which is defined at

We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec since in OAuth, there are lots of possible relationships between authorization servers and resource servers and they needn’t be one-to-one, as is being actively discussed by the working group.  For instance, see George Fletcher’s recent contribution.

Thanks for the good discussion, Phil.

                                                                -- Mike

From: Phil Hunt (IDM) []
Sent: Wednesday, February 24, 2016 1:25 PM
To: Mike Jones
Cc: <<>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Where is the profile endpoint (oidc's resource server) published? (For the non OIDC people on the list).


On Feb 24, 2016, at 13:09, Mike Jones <<>> wrote:
To the extent that generic OAuth 2.0 needs to publish some of the same information as OpenID Connect – which is built on generic OAuth 2.0 – it makes sense to publish that information using exactly the same syntax, since that syntax is already in widespread use.  That what this draft accomplishes.

There’s nothing Connect-specific about using metadata response values like:

   "authorization_endpoint": "",
   "token_endpoint": "",
   "token_endpoint_auth_methods_supported": ["client_secret_basic", "private_key_jwt"],
   "registration_endpoint": "",
   "response_types_supported":  ["code", "token"],
   "service_documentation": "",

Is there a reason that you would like the syntax for any of these or the other generally applicable OAuth 2.0 metadata values to be different?  I don’t see any good reason for unnecessary differences to be introduced.

                                                                -- Mike

From: Phil Hunt (IDM) []
Sent: Wednesday, February 24, 2016 12:45 PM
To: Anthony Nadalin <<>>
Cc: Mike Jones <<>>; <<>> <<>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location


Publishing on dev pages does not work for software (esp open source) that is deployed both in enterprises and on PaaS cloud providers.

The current draft is may codify current OIDC practice and be appropriate for oidc but it is not ready for generic oauth. There is no generic oauth experience at this time.


On Feb 24, 2016, at 10:25, Anthony Nadalin <<>> wrote:
Sure there is, it is as you have now made it far easier and the security considerations does not even address this

From: Mike Jones
Sent: Wednesday, February 24, 2016 10:22 AM
To: Anthony Nadalin <<>>
Cc: <<>> <<>>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

As we’d discussed in person, there’s no effective security difference between discovery information being published in an ad-hoc fashion on developer pages and it being published in a standard format.  “Security by obscurity” adds no real security at all.

                                                          -- Mike

From: Anthony Nadalin
Sent: Wednesday, February 24, 2016 10:01 AM
To: Mike Jones <<>>; Phil Hunt (IDM) <<>>; Nat Sakimura <<>>
Cc: <<>> <<>>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location

> The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.

That may be widely deployed for OIDC but not widely deployed for OAuth. There are some authentication mechanism discovery for endpoint that really should not be in an OAuth standard since it’s really not dealt with. Now that all this information is available it makes poking around the endpoint more focused for people that want to disrupt your endpoints, that is really not addressed in the security considerations section at all

From: OAuth [] On Behalf Of Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) <<>>; Nat Sakimura <<>>
Cc: <<>> <<>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

The point of the WGLC is to finish standardizing the core discovery functionality that’s already widely deployed.

None of Nat or John or I are suggesting that additional related functionality won’t be created.  I’m sure it will be.  Some applications will use WebFinger to locate the discovery metadata.  Some will possibly use link headers.  Some will possibly use application-specific .well-known values.  I’m sure there’s other things I haven’t even thought about.  All of these depend upon having a discovery metadata document format and none of them change it – other than possibly to register additional discovery metadata values.

So by all means, the working group should continue discussing inventing possible new related mechanisms that make sense in some contexts.  At the same time, we can finish standardizing the already widely deployed core functionality that all of these mechanisms will need.

                                                          -- Mike

From: OAuth [] On Behalf Of Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura <<>>
Cc: <<>> <<>>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I am suggesting that part of the discovery solution has to be the client indicating what resource endpoint it wants the oauth configuration data for.

So if<> is not a valid resource endpoint for<> the authz discovery should fail in some way (eg return nothing).

There may be better ways to do this. Eg combine discovery. Or change the order of discovery.

One of OAuth's strength's and weaknesses is that the target of authorization (the resource) is never specified. It is often bound up in the client registration and an often implied 1:1 relationship between resource and as. Given that in discovery phase registration has not yet occurred it seems important that the client know it has a valid combination of endpoints etc.

This is why I was disappointed about wglc on discovery. We had a starting point for group adoption but we haven't really defined the full requirements IMO.

I am on vacation or I would put some thought into some draft changes or a new draft. I apologize I can't do it now.


On Feb 24, 2016, at 08:12, Nat Sakimura <<>> wrote:
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 <<>>:

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.



On Feb 24, 2016, at 3:54 AM, Nat Sakimura <<>> wrote:

Hi Thomas,


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.



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<><>

OAuth mailing list<>