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. > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
