I agree, BUT. I don't think it is very practical at this point. Defining new authentication schemes (i.e. SAML assertion) means slower deployment due to lack of support in existing applications. Reusing existing authentication schemes for a new set of credentials has its own deployment challenges (conflict with another set of credentials like users, access to header from clients, reliance on different layers of the infrastructure).
As currently written, the spec defines a new authentication scheme using assertions (which if defined as a general purpose scheme requires much more specificity than this group shown an interest in), and provides an alternative to Basic using parameters instead of headers. I would be opposed to this group spending time on a general purpose assertion authentication scheme (but don't care if someone decides to create one elsewhere). As for using Basic, I don't have a strong objection but I am certain it will cause confusion and will make the spec harder to use. There is nothing to stop anyone from defining new flows which use other authentication methods. The spec offers a practical set that is in line with how most of the participants expect to deploy it. So while I agree with your sentiment here, I would not be supportive of it unless the primary companies looking to deploy this in the next few months are on board. I have no interest in producing a cleaner spec that no one wants to use. OAuth has been successful in the past primarily because pragmatism is the OAuth way. EHL On 4/12/10 4:09 PM, "James Manger" <[email protected]> wrote: 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.
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
