Requests from a client app to collect an access token don’t need to use an OAuth-specific client authentication mechanism.
A service that issues a client app with credentials (eg a client_id and client_secret) is very likely to offer APIs specifically for clients, in addition to APIs for clients acting on behalf of users. Facebook, for instance, has APIs allowing an app to get and set various app properties, limits, metrics etc. It makes most sense for all the calls from the client (acting on its own behalf) to the service to use the same authentication mechanism. Most of these calls have nothing to do with OAuth so they will use standard (or proprietary) authentication mechanisms that have nothing to do with OAuth. A client’s call to get an access token should be authenticated just like non-OAuth client calls. For the various requests from a client app to the authorization server (AS), OAuth should just say the AS may require the client to be authenticated to make the calls. This affects the Web Callback Flow (3.4.1.2), Username and Password Flow (3.5.1.1), Client Credential Flow (3.6.1.1), and Refreshing an Access Token (4). Basically any request with client_id and client_secret should has these parameters removed. It is still useful to identify the client app when redirecting the user to the AS. The client_id parameter should be kept here (though it needs to be optional so OAuth supports unregistered apps). Without decoupling client auth from OAuth requests, client apps have to implement different auth mechanisms for different API calls. They also need to use the same client_secret in two different mechanisms, which is never good for security. Finally, if the non-OAuth calls aren’t authenticated with a shared-secret (eg they use SAML, or TLS client certs…) the burden is even worse as the client now needs multiple types of credentials for authenticating itself to the same service. The OAuth spec could use HTTP BASIC as an example mechanism for client authentication if it needs one in examples, though I don’t think it needs to recommend anything. On a related note, I think the SAML flow would be better if designed as a mechanism to “authenticate” any HTTP request. For instance, a “Authorization: SAML assertion=ghfHGFHGFGHF76576” header. It can be specified completely independently of OAuth (even if that is in another section of the same spec). This general mechanism can be used to “authenticate” a request for an access token, or a call to renew a token. -- James Manger
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
