+1 for “OAuth 2.0 Authorization Server Discovery” //Samuel
On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones <michael.jo...@microsoft.com> wrote: > Thanks for your thoughts, Vladimir. I’m increasingly inclined to accept > your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth > 2.0 Authorization Server Discovery”. While the abstract already makes it > clear that the scope of the document is AS discovery, doing so in the title > seems like it could help clarify things, given that a lot of the discussion > seems to be about resource discovery, which is out of scope of the document. > > > > I’m not saying that resource discovery isn’t important – it is – but > unlike authorization server discovery, where there’s lots of existing > practice, including using the existing data format for describing OAuth > implementations that aren’t being used with OpenID Connect, there’s no > existing practice to standardize for resource discovery. The time to > create a standard for that seems to be after existing practice has > emerged. It **might** or might not use new metadata values in the AS > discovery document, but that’s still to be determined. The one reason to > leave the title as-is is that resource discovery might end up involving > extensions to this metadata format in some cases. > > > > I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 > applies. 6749 is about the AS. 6750 is about the RS. The discovery > document is about the AS. We don’t yet have a specification or existing > practice for RS discovery, which would be the 6750 analogy. > > > > In summary, which title do people prefer? > > · “OAuth 2.0 Discovery” > > · “OAuth 2.0 Authorization Server Discovery” > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vladimir > Dzhuvinov > *Sent:* Thursday, February 25, 2016 12:59 AM > *To:* oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location > > > > In OIDC the discovery doc is of great utility to developers and > integrators. Developers also tend to find it a more accurate and complete > description of how to set up a client for a particular deployment, compared > to traditional online docs, which may be not be up to date, or even > missing. Very much like auto-generated Swagger and JavaDocs. > > Here are some example OIDC discovery docs: > > https://accounts.google.com/.well-known/openid-configuration > > https://www.paypalobjects.com/.well-known/openid-configuration > > > https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration > > > With this discovery document in place setup of identity federation can > then be easily scripted. For example: > > > http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html > > > Now, does that dictate any particular app architecture? My reading of the > spec is that it doesn't, and it shouldn't either. By staying neutral on the > topics of RS discovery and registering RPs with RSs. And how one arrives at > the ".well-known/...". I'm not even sure that resource discovery should be > a topic of this WG. Perhaps to this end, and to prevent confusion that the > spec is trying to do something more, a more specific title would suit it > better. E.g. "AS Discovery". > > Cheers, > > Vladimir > > > > On 25/02/16 02:25, Phil Hunt (IDM) wrote: > > And so does oracle and so does google. Each different. > > > > So how can an app dictate it then unless we all go to a common architecture? > > > > Phil > > > > On Feb 24, 2016, at 16:04, Mike Jones <michael.jo...@microsoft.com> > <michael.jo...@microsoft.com> wrote: > > > > Azure defines ways for resource servers to be registered for use with a > client and for clients to dynamically request an access token for use at a > particular resource server. You can call that custom architecture if you > want. It’s well-defined but it’s not currently in the standards realm. I > know that Google has syntax for doing the same, as I’m sure do a lot of other > cloud OAuth deployments, such as Oracle’s. For what it’s worth, the working > group talked about possibly producing a standard version of syntax for making > these kinds of requests during our discussions in Prague (during the Token > Exchange discussion) but nobody has run with this yet. > > In this sense, yes, Azure is an application of the kind we’re talking about. > Azure already does define specific new OAuth 2.0 discovery metadata values > that are used in production. A registry just doesn’t yet exist in which it > can register those that are of general applicability. > > -- Mike > > From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com <phil.h...@oracle.com>] > > Sent: Wednesday, February 24, 2016 3:52 PM > > To: Mike Jones > > Cc: <oauth@ietf.org> <oauth@ietf.org> > > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location > > Mike > > Take a look at the assumptions you are making. > > > > You seem to be assuming application software dictates oauth infrastructure > architecture by suggesting that apps register in iana. > > > > Would ms azure allow custom arch? > > > > Phil > > > > On Feb 24, 2016, at 15:28, Mike Jones <michael.jo...@microsoft.com> > <michael.jo...@microsoft.com> wrote: > > > > 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) [mailto:phil.h...@oracle.com <phil.h...@oracle.com>] > > Sent: Wednesday, February 24, 2016 2:13 PM > > To: Mike Jones <michael.jo...@microsoft.com> <michael.jo...@microsoft.com> > > Cc: <oauth@ietf.org> <oauth@ietf.org> <oauth@ietf.org> <oauth@ietf.org> > > 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. > > > > Phil > > > > On Feb 24, 2016, at 14:05, Mike Jones <michael.jo...@microsoft.com> > <michael.jo...@microsoft.com> 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 > http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata. > > 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) [mailto:phil.h...@oracle.com <phil.h...@oracle.com>] > > Sent: Wednesday, February 24, 2016 1:25 PM > > To: Mike Jones > > Cc: <oauth@ietf.org> <oauth@ietf.org> > > 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). > > > > Phil > > > > On Feb 24, 2016, at 13:09, Mike Jones <michael.jo...@microsoft.com> > <michael.jo...@microsoft.com> 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": "https://server.example.com/authorize"; > <https://server.example.com/authorize>, > > "token_endpoint": "https://server.example.com/token"; > <https://server.example.com/token>, > > "token_endpoint_auth_methods_supported": ["client_secret_basic", > "private_key_jwt"], > > "registration_endpoint": "https://server.example.com/register"; > <https://server.example.com/register>, > > "response_types_supported": ["code", "token"], > > "service_documentation": > "http://server.example.com/service_documentation.html"; > <http://server.example.com/service_documentation.html>, > > 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) [mailto:phil.h...@oracle.com <phil.h...@oracle.com>] > > Sent: Wednesday, February 24, 2016 12:45 PM > > To: Anthony Nadalin <tony...@microsoft.com> <tony...@microsoft.com> > > Cc: Mike Jones <michael.jo...@microsoft.com> <michael.jo...@microsoft.com>; > <oauth@ietf.org> <oauth@ietf.org> <oauth@ietf.org> <oauth@ietf.org> > > Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location > > Mike > > 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. > > > > Phil > > > > On Feb 24, 2016, at 10:25, Anthony Nadalin <tony...@microsoft.com> > <tony...@microsoft.com> 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 <tony...@microsoft.com> <tony...@microsoft.com> > > Cc: <oauth@ietf.org> <oauth@ietf.org> <oauth@ietf.org> <oauth@ietf.org> > > 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 <michael.jo...@microsoft.com> <michael.jo...@microsoft.com>; > Phil Hunt (IDM) <phil.h...@oracle.com> <phil.h...@oracle.com>; Nat Sakimura > <sakim...@gmail.com> <sakim...@gmail.com> > > Cc: <oauth@ietf.org> <oauth@ietf.org> <oauth@ietf.org> <oauth@ietf.org> > > 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 [mailto:oauth-boun...@ietf.org <oauth-boun...@ietf.org>] On > Behalf Of Mike Jones > > Sent: Wednesday, February 24, 2016 9:54 AM > > To: Phil Hunt (IDM) <phil.h...@oracle.com> <phil.h...@oracle.com>; Nat > Sakimura <sakim...@gmail.com> <sakim...@gmail.com> > > Cc: <oauth@ietf.org> <oauth@ietf.org> <oauth@ietf.org> <oauth@ietf.org> > > 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 [mailto:oauth-boun...@ietf.org <oauth-boun...@ietf.org>] On > Behalf Of Phil Hunt (IDM) > > Sent: Wednesday, February 24, 2016 8:39 AM > > To: Nat Sakimura <sakim...@gmail.com> <sakim...@gmail.com> > > Cc: <oauth@ietf.org> <oauth@ietf.org> <oauth@ietf.org> <oauth@ietf.org> > > 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 res.example.evil.com is not a valid resource endpoint for > as.example.com 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. > > > > Phil > > > > On Feb 24, 2016, at 08:12, Nat Sakimura <sakim...@gmail.com> > <sakim...@gmail.com> 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. > > > > Nat > > 2016年2月24日(水) 23:59 Phil Hunt <phil.h...@oracle.com> <phil.h...@oracle.com>: > > 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 > > www.independentid.com > > phil.h...@oracle.com > > > > > > > > On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakim...@gmail.com> > <sakim...@gmail.com> wrote: > > > > Hi Thomas, > > > > inline: > > > > 2016年2月22日(月) 18:44 Thomas Broyer <t.bro...@gmail.com> <t.bro...@gmail.com>: > > 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 <jric...@mit.edu> > <jric...@mit.edu> 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@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > > Vladimir Dzhuvinov :: vladi...@connect2id.com > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
