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 <e...@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" <mscurte...@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
