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

[Justin Richer <[e-mail]>]

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. 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.
>