+1 for “OAuth 2.0 Authorization Server Discovery” — Justin
> On Feb 25, 2016, at 2:20 PM, George Fletcher <gffle...@aol.com> wrote: > > +1 for “OAuth 2.0 Authorization Server Discovery” > > On 2/25/16 2:10 PM, Mike Jones 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 <mailto:oauth-boun...@ietf.org>] >> On Behalf Of Vladimir Dzhuvinov >> Sent: Thursday, February 25, 2016 12:59 AM >> To: oauth@ietf.org <mailto: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://accounts.google.com/.well-known/openid-configuration> >> >> https://www.paypalobjects.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 >> >> <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 >> >> <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> >> <mailto: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 >> <mailto:phil.h...@oracle.com>] >> Sent: Wednesday, February 24, 2016 3:52 PM >> To: Mike Jones >> Cc: <oauth@ietf.org> <mailto: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> >> <mailto: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 >> <mailto:phil.h...@oracle.com>] >> Sent: Wednesday, February 24, 2016 2:13 PM >> To: Mike Jones <michael.jo...@microsoft.com> >> <mailto:michael.jo...@microsoft.com> >> Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> >> <mailto: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> >> <mailto: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 >> <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 >> <mailto:phil.h...@oracle.com>] >> Sent: Wednesday, February 24, 2016 1:25 PM >> To: Mike Jones >> Cc: <oauth@ietf.org> <mailto: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> >> <mailto: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 >> <mailto:phil.h...@oracle.com>] >> Sent: Wednesday, February 24, 2016 12:45 PM >> To: Anthony Nadalin <tony...@microsoft.com> <mailto:tony...@microsoft.com> >> Cc: Mike Jones <michael.jo...@microsoft.com> >> <mailto:michael.jo...@microsoft.com>; <oauth@ietf.org> >> <mailto:oauth@ietf.org> <oauth@ietf.org> <mailto: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> >> <mailto: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> <mailto:tony...@microsoft.com> >> Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> >> <mailto: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> >> <mailto:michael.jo...@microsoft.com>; Phil Hunt (IDM) <phil.h...@oracle.com> >> <mailto:phil.h...@oracle.com>; Nat Sakimura <sakim...@gmail.com> >> <mailto:sakim...@gmail.com> >> Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> >> <mailto: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 <mailto: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> <mailto:phil.h...@oracle.com>; >> Nat Sakimura <sakim...@gmail.com> <mailto:sakim...@gmail.com> >> Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> >> <mailto: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 <mailto:oauth-boun...@ietf.org>] >> On Behalf Of Phil Hunt (IDM) >> Sent: Wednesday, February 24, 2016 8:39 AM >> To: Nat Sakimura <sakim...@gmail.com> <mailto:sakim...@gmail.com> >> Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> >> <mailto: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> >> <mailto: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> >> <mailto: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 <http://www.independentid.com/> >> phil.h...@oracle.com <mailto:phil.h...@oracle.com> >> >> >> >> >> >> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakim...@gmail.com> >> <mailto:sakim...@gmail.com> wrote: >> >> >> Hi Thomas, >> >> inline: >> >> 2016年2月22日(月) 18:44 Thomas Broyer <t.bro...@gmail.com> >> <mailto: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> >> <mailto: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 <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> >> -- >> Vladimir Dzhuvinov :: vladi...@connect2id.com >> <mailto:vladi...@connect2id.com> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <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
