Re: [OAUTH-WG] Issue: Split the authorization endpoint into two endpoints

On Fri, Apr 16, 2010 at 7:01 AM, Justin Richer <jricher@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
>