Re: [OAUTH-WG] OAuth 2.0: client_secret, state

[Luke Shepard <[e-mail]>]

Few responses inline.

On Mar 22, 2010, at 5:11 AM, Manger, James H wrote:

> 1. CLIENT SECRET
> Client authentication needs to be independent of OAuth.
> The Web Server Flow sends oauth_client_secret to the access token request endpoint along with other oauth_ parameters. This is a poor design.
> 
> Consider, for instance, a service that authenticates clients with TLS client certs. Such clients don't have a shared secret to put in the oauth_client_secret parameter so they cannot perform protocol in this OAuth 2 draft.
> Even if client certs are rare, the issue is that there is no reason why client certs should prevent OAuth 2 from working.
> 
> Servers that can authenticate clients are likely to offer them various APIs in addition to the OAuth get-a-token calls. The same client authentication mechanism used for those calls should be reused for the get-a-token calls.
> 
> I suggest dropping the oauth_client_secret, perhaps adding text such as:
> "Servers that require clients to be pre-registered may require this client request to be authenticated."
> 

It would be great to support client certificates as a means to authenticate OAuth applications. However, that should be a new flow, as it has different security characteristics.

<snip>

> 4. The Username and Password Flow has oauth_client_secret in the example but not in the expected list of parameters.

Mistake. It should not have client secret. This flow also could benefit from client certs, if available, but again, that is a new flow definition.

> 5. Just call it TLS (not TLS/SSL).

Many people are familiar with SSL, not TLS, and so this clarifies for those readers.