On Fri, Apr 16, 2010 at 7:01 AM, Justin Richer <jric...@mitre.org> wrote:
> I favor this approach as well. It feels cleaner to me to have a > separation of purposes here. The two endpoints could always be collapsed > in a particular implementation -- I've seen several OAuth 1.0 > implementations that do just this, using a URL parameter to > differentiate between the request, access, and authorization endpoints. > > Having them available separately makes it easier to have different > authentication mechanisms to the endpoints themselves, as well. The > authorization endpoint is (generally) user-credential protected, but the > token endpoint will be authenticated differently depending on which > flows are supported. Any flow where the user interacts on a domain that will have the user credentials (cookies, etc). This is often a different URL path or even domain from endpoints where a user credential isn't required. Think I'd lean towards two URLs - the downside is that it makes discovery / configuration a little bit harder. > However, I will say that in most webapp systems, > you can always have the OAuth endpoint forward internally to another > endpoint if user authentication is necessary, so this argument may not > hold up in practical deployment. > > Downside is that it does make discovery a little trickier, but discovery > is admittedly outside the scope of this protocol. > > -- justin > > On Thu, 2010-04-15 at 21:22 -0400, 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 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. > > > > > _______________________________________________ > 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
