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-boun...@ietf.org [mailto:oauth-boun...@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-boun...@ietf.org [mailto:oauth-boun...@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" <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 _______________________________________________ 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
