Talked with Luke and now remember earlier conversations about two URLs. We'll likely do www.facebook.com for user interactions and api.facebook.com for server stuff.
On Fri, Apr 16, 2010 at 9:58 AM, Luke Shepard <[email protected]> wrote: > 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: [email protected] [mailto:[email protected]] 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: [email protected] [mailto:[email protected]] 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" <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
