Subject: [OAUTH-WG] No client_id parameter in resource requests

From: Paul Walker <[email-masked]>
Date: Wed, 15 Dec 2010 12:22:44 -0800

What is the reasoning behind the lack of a client_id parameter in requests to protected resources?  Could it not add value if a resource server wanted to provide IP white-lisitng (in a server to server scenario), in that the resource server would not have to decrypt/look up the client before denying the request?  Also, it would alleviate the need to create provider wide unique access token values.  There is probably some security reasoning behind this that I don't understand...can someone kindly inform me?  :-).

Thanks,
~pj

---

From: Paul Lindner <[email-masked]>
Date: Wed, 15 Dec 2010 12:43:28 -0800

You want the client_id on each API request?  Put it in the token or
make it part of your API.  The token is opaque for a reason.

On Wed, Dec 15, 2010 at 12:22 PM, Paul Walker <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Paul Lindner -- [email-masked] -- linkedin.com/in/plindner

---

From: Phil Hunt <[email-masked]>
Date: Wed, 15 Dec 2010 14:18:31 -0800

From the spec, from section 5, draft 11 obtaining the access token includes it...

"The client obtains an access token by authenticating with the authorization server and presenting its access grant (in the form of an authorization code, resource owner credentials, an assertion, or a refresh token)."

But, when accessing the resource (sect 6), I agree it is unclear. I am assuming the there is some method that binds the active client with the resource access token (much like an SSO cookie does in a browser). I am concerned about issues similar to SAML 1.1 browser artifact profile and having the necessary counter-measures.  See section 4.1.1 of this document:
http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-bindings-1.1.pdf

Phil
[email-masked]

---

From: Paul Walker <[email-masked]>
Date: Wed, 15 Dec 2010 15:00:04 -0800

The same capability to store the client_id in an opaque value holds true for the authorization code and refresh token, yet the client_id parameter is required in those requests.  Although section 5.0 does not actually say the client_id is required in access token requests, but the examples in 5.1.1 and 5.1.4 have the client_id present.

~pj

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 16 Dec 2010 10:09:59 +1000

Ø  What is the reasoning behind the lack of a client_id parameter in requests to protected resources?

When the client app is acting on its own behalf (with the app's own long-term credentials)... the client_id is included as part of authenticating the client app (as a query/form parameter, or as the user-id field in a "Authorization: BASIC" header, or in any other authentication mechanism).

When the client app is acting on behalf of a user (with credentials from an OAuth token response)... the client_id is NOT included. The credentials from the token response are sufficient. Adding client_id here is unnecessary (the server can include it in the token if it is convenient for protected resources), and harmful (it means the protocol that uses the credentials from the token response cannot look like a normal authentication protocol).

--

James Manger

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 15 Dec 2010 19:30:42 -0500

James,

Could you please clarify the last point (i.e., "cannot look like a 
normal authentication protocol")?  I simply don't understand what you mean.

With thanks,

Igor

Manger, James H wrote:
>
> .... Adding client_id here is unnecessary (the server can include it 
> in the token if it is convenient for protected resources), and harmful 
> (it means the protocol that uses the credentials from the token 
> response cannot look like a normal authentication protocol).
>
>  
>
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 15 Dec 2010 17:19:29 -0800

See below..

Phil
[email-masked]

On 2010-12-15, at 4:09 PM, Manger, James H wrote:

> When the client app is acting on its own behalf (with the app’s own long-term credentials)… the client_id is included as part of authenticating the client app (as a query/form parameter, or as the user-id field in a “Authorization: BASIC” header, or in any other authentication mechanism).
>  
> When the client app is acting on behalf of a user (with credentials from an OAuth token response)… the client_id is NOT included. The credentials from the token response are sufficient. Adding client_id here is unnecessary (the server can include it in the token if it is convenient for protected resources), and harmful (it means the protocol that uses the credentials from the token response cannot look like a normal authentication protocol).

It is useful for the resource authorization policy server to know what client is acting on behalf of what user.  E.g. if a financial aggregator was using OAuth to access a bank, the bank systems can differentiate rights between normal end-user access and a client app access (e.g. read-only regardless of scope).  I know scope already covers some of this, but it seems like an important distinction if for some reason a policy server needs to apply additional rules for clients beyond those of scope.

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 16 Dec 2010 12:49:14 +1100

Phil,

> It is useful for the resource authorization policy server to know what client is acting on behalf of what user.  E.g. if a financial aggregator was using OAuth to access a bank, the bank systems ca…

It certainly makes sense for a bank "protected resource" to be able to distinguish requests from (1) a financial aggregator app acting on a user's behalf, and (2) requests from the user. But the bank gets that by arranging with the authorization server (also the bank) to issue tokens that distinguish those cases. Eg user-ids are 16-digit credit card numbers; tokens issued to client apps start with "DELEGATE_...". The client app need not care how the bank does this. It does not need the OAuth2 framework to specify an explicit client_id parameter to include in those requests.

--

James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 16 Dec 2010 13:28:06 +1100

Igor,

> normal authentication protocol")?  I simply don't understand what you mean.

Perhaps an example would help. Consider a server (of protected resources) that authenticates requests using the HTTP DIGEST scheme (or substitute any other request signing scheme that is not OAuth-specific).

If it wants, the server can authenticate requests directly from users: by returning WWW-Auth: DIGEST... to trigger the browser to prompt the user for their password.

To support delegated access (requests from a client app on a user's behalf) the server tells the client app to orchestrate an OAuth2 flow. The client app ends up with a token response that contains credentials to use with the HTTP DIGEST scheme (ie a user-id/password pair that represents this delegation).

The client app now makes requests on the user's behalf to the server using "normal" HTTP DIGEST. On the wire, these requests are totally standard HTTP DIGEST authentication requests (so they can use totally standard implementations and APIs).

There is no extra client_id field in the HTTP DIGEST scheme. It does take an id, but in this context that is the id of the delegation (client app X acting for user Y). DIGEST assumes a model  with two parties that shared a secret -- it simply has no use for the extra concept of a third party, and neither will any other "normal" authentication protocol.

I believe the SASL model is a bit more sophisticated. It includes 2 ids: an authentication_id and an authorization_id. But neither of those would correspond to client_id. The authorization_id could be a bearer token (when there is no authentication_id); or the authentication_id could be the id from a token response that had a secret key (and the authorization_id could be the user-id).

If the OAuth framework spec forced an explicit client_id parameter into requests for protected resources it would be unusable with HTTP DIGEST (and every other authentication scheme, past and future, that is not OAuth-specific).

Is my meaning any clearer now?

--
James Manger

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 16 Dec 2010 10:00:28 -0500

James,

Yes, I understand you now and I agree with you.

With thanks,

Igor