Re: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints

I guess I would prefer two URLs as well, but I see the simplicity argument as well:

>> Constraints for endpoints:
>> access token URL: HTTPS and POST only, no user
>> user authentication URL: HTTP or HTTPS, GET or POST, authenticated user

In either case, we should not restrict the access token URL to POST-only. A GET request is just as secure and can be much easier to write code for (just construct the URL and ping, no need to figure out CURLOPT_POSTFIELDS).

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of John Kemp
Sent: Thursday, April 15, 2010 7:11 PM
To: Manger, James H
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints

On Apr 15, 2010, at 9:22 PM, Manger, James H wrote:

> I strongly favour specifying 2 separate endpoints: one for where to redirect a user, another for direct client calls.

I agree.

> 
> I agree with Marius that these two endpoints are different enough to be separate.
> One is only used by users via browsers. The other is only used by client apps. These are different populations, using different authentication mechanisms, with different performance requirements, and different technologies.
> 
> The use of a type parameter is a poor tool to distinguishes these cases.
> 
> I guess 1 URI could default to the other if not defined.
> 1 URI could be allowed to be relative to the other to save some bytes.

I agree with this reasoning too. 

- johnk

> 
> -- 
> James Manger
> 
> 
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
> Sent: Friday, 16 April 2010 4:41 AM
> To: OAuth WG
> Subject: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints
> 
> OAuth 2.0 defines a single authorization endpoint with a 'type' parameter
> for the various flows and flow steps. There are two types of calls made to
> the authorization endpoint:
> 
> - Requests for Access - requests in which an end user interacts with the
> authorization server, granting client access.
> 
> - Requests for Token - requests in which the client uses a verification code
> or other credentials to obtain an access token. These requests require
> SSL/TLS because they always result in the transmission of plaintext
> credentials in the response and sometimes in the request.
> 
> A proposal has been made to define two separate endpoints due to the
> different nature of these endpoints:
> 
> On 4/6/10 4:06 PM, "Marius Scurtescu" <mscurtescu@google.com> wrote:
> 
>> Constraints for endpoints:
>> access token URL: HTTPS and POST only, no user
>> user authentication URL: HTTP or HTTPS, GET or POST, authenticated user
>> 
>> In many cases the above constraints can be enforced with configuration
>> that sits in front of the controllers implementing these endpoints.
>> For example, Apache config can enforce SSL and POST. Same can be done
>> in a Java filter. Also a Java filter can enforce that only
>> authenticated users hit the endpoint, it can redirect to a login page
>> if needed.
>> 
>> By keeping two different endpoints all of the above is much simpler.
>> Nothing prevents an authz server to collapse these two into one
>> endpoint.
> 
> While requests for access do not require HTTPS, they should because they
> involve authenticating the end user. As for enforcing HTTP methods (GET,
> POST), this is simple to do both at the server configuration level or
> application level.
> 
> On the other hand, having a single endpoint makes the specification simpler,
> and more importantly, makes discovery trivial as a 401 response needs to
> include a single endpoint for obtaining a token regardless of the flow (some
> flows use one, others two steps).
> 
> A richer discovery later can use LRDD on the single authorization endpoint
> to obtain an XRD describing the flows and UI options provided by the server.
> But this is outside our scope.
> 
> Proposal: No change. Keep the single authorization endpoint and require
> HTTPS for all requests.
> 
> EHL
> 
> 
> 
> 
> 
> _______________________________________________
> 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