Re: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints (OpenId comparison)

[Torsten Lodderstedt <[e-mail]>]

sounds good.

One question arose: OpenId has the same design challenge. There are 
direct calls, like "associate", as well as indirect calls, like 
"checkid_setup". OpenId uses a single endpoint on the OP and 
differentiate the request types via the openid.mode parameter.

Does anyone know why OpenId want that way?

Am 16.04.2010 22:51, schrieb Eran Hammer-Lahav:
> I'll split them to: Authorization endpoint and Toke endpoint. In the 
> WWW-Authenticate header I'll add a parameter for each (instead of one) 
> for lightweight discovery (which we can keep, change, or drop later).
>
> EHL
>
>
> On 4/15/10 6:22 PM, "James Manger" <[e-mail]> 
> wrote:
>
>     I strongly favour specifying 2 separate endpoints: one for where
>     to redirect a user, another for direct client calls.
>
>     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.
>
>     --
>     James Manger
>
>
>     -----Original Message-----
>     From: [e-mail] [mailto:[e-mail]] 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" <[e-mail]> 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
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>