Subject: [OAUTH-WG] authenticating client-to-authz.server calls

From: "Manger, James H" <[email-masked]>
Date: Tue, 13 Apr 2010 09:09:43 +1000

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

---

From: Luke Shepard <[email-masked]>
Date: Mon, 12 Apr 2010 18:29:06 -0700

In Facebook’s case, we would like to make our entire API accessible exclusively via OAuth – including properties, metrics, etc. For our purposes, I think the Client Credentials Flow (http://github.com/theRazorBlade/draft-ietf-oauth/blob/master/draft-ietf-oauth.txt#L1869) is sufficient. I prefer the consistency and simplicity of the access token even though it means an extra server call.

In the Client Credentials Flow, the client_secret is already optional, which leaves it up to the server to authenticate via other means (for example, client cert or whatever).

Many of the security assumptions in the spec only hold true if a secret is passed. I’m not comfortable leaving so much up to the developer. Perhaps we could have a section that says “It is okay to drop the client secret wherever it is requested, as long as alternative equally strong authentication measures are taken.”

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Monday, April 12, 2010 4:10 PM
To: OAuth WG
Subject: [OAUTH-WG] authenticating client-to-authz.server calls

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 13 Apr 2010 12:30:55 +1000

Switching exclusively to token-based access for all APIs is one reasonable approach. However this shouldn’t be required for services that just want to support the user-delegation part of OAuth.

If Facebook used OAuth exclusively, then the only time a client_secret would be used is when requesting (or renewing) an access token. There is only 1 URI where the secret is used so you may better off just issuing each app its own secret URI for getting access tokens, and not bother to separate URI, id and secret.

I guess OAuth could support a client_secret parameter as one authentication mechanism. However, it feels like a poor (and unnecessary) choice to me. We already have simple & standard ways to authenticate requests with a shared secret. They come with library support, discovery (eg 401 WWW-Auth.: BASIC ...), and control (eg whether or not to include the secret after a redirect). Plus obvious ways to swap to any other sort of client authentication if desired.

--

James Manger

From: Luke Shepard [mailto:[email-masked]]
Sent: Tuesday, 13 April 2010 11:29 AM
To: Manger, James H; OAuth WG
Subject: RE: [OAUTH-WG] authenticating client-to-authz.server calls

--

James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 12 Apr 2010 23:26:13 -0700

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-masked]> wrote:

Requests from a client app to collect an access token don't need to use an OAuth-specific client authentication mechanism.

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.

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.

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 13 Apr 2010 18:00:17 +1000

Eran,

> I agree

Thanks.

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

There are no existing apps that support the SAML flow as it was only written a few days ago. I guess some might support the WRAP SAML flow. It is incompatible, but similar enough for an easy change. But moving the fields to a “Authorization: SAML” header is easy too.

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

I don’t think this is an issue since requests for an access token are only done by client apps, not users.

Also the credentials will often not be a new set. They will be client credentials used to access non-OAuth-protected resources already.

Access to header from client, reliance on different layers etc could be issues — but that is a great reason for OAuth not to try to pick one answer. One answer has no chance of satisfying everyone, hence items like the SAML flow being introduced.

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

I also don’t want the group spending time on general purpose assertion auth (or request auth) schemes.

The only way to avoid that is to decouple them from OAuth-specific bits. This is what I am suggesting.

Currently, people who want to use SAML (which is not me particularly) need to argue about OAuth core because the other OAuth flows prevent use of SAML by choosing an OAuth-specific shared secret mechanism. Recognizing that OAuth access token requests are independent of client auth would really help. It would be obvious how to use OAuth (unchanged) with other client auth mechanisms.

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

I am equally certain that client developers will not be confused at all if a service says “use HTTP BASIC with your client id and secret to authenticate calls to the AS to get and renew access tokens”.

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

The fact that WRAP redid OAuth, and the IETF are redoing it again -- with no backward compatibility -- suggests to me that we didn’t take quite enough time to cleanly separate the aspects of the spec that can be independent. I hope we don’t make the same mistake again.

I doubt any of the “primary companies looking to deploy this in the next few months” need interoperability from client apps not written specifically for their proprietary API, at least not “in the next few months”, but I think an IETF OAuth spec must provide that.

--

James Manger

---

From: Allen Tom <[email-masked]>
Date: Tue, 13 Apr 2010 12:10:05 -0700

+1 

In Yahoo¹s case, we would also like to use the Client Credentials Flow for
all ³2 legged² APIs.

Allen

On 4/12/10 6:29 PM, "Luke Shepard" <[email-masked]> wrote:

> In Facebook¹s case, we would like to make our entire API accessible
> exclusively via OAuth  including properties, metrics, etc. For our purposes,
> I think the Client Credentials Flow
> (http://github.com/theRazorBlade/draft-ietf-oauth/blob/master/draft-ietf-oauth
> .txt#L1869) is sufficient. I prefer the consistency and simplicity of the
> access token even though it means an extra server call.