+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

Reply via email to