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

Strongly for keeping one endpoint given that the spec uses type
extensively. A huge motivator in the 2.0 effort is simplicity for
client developers.

On Thu, Apr 15, 2010 at 11:41 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> 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
>