Subject: [OAUTH-WG] Method of validating client id & client secret for authenticated requests?

From: Steve Hoeksema <[email-masked]>
Date: Thu, 17 Mar 2011 17:21:11 +1300

Hi all,

I'm evaluating whether OAuth 2 draft 13 w/ MAC authentication will be suitable for my situation.

We have an API which will be consumed by approved native apps on mobile devices. For business reasons I want to ensure that a user cannot use their own valid access token to make API calls from non-approved clients.

Perhaps this is not what OAuth is designed to protect against, but I'd like to use a standardized authentication method if at all possible.

I understand the process of granting an access token to clients validated by client_id and client_secret, but I want to do the same for all authenticated requests.
As far as I can tell, an an authenticated request is signed by an access token and token secret, but not client id and client secret.

I'm aware that determined users could extract the client ID and client secret from mobile app binaries, but this should stop casual users.

I've found a couple of discussions related to this problem, but I'm not sure if they're what I'm after -

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg03836.html
[2] http://www.ietf.org/mail-archive/web/oauth/current/msg04872.html

It might be possible to include the client ID and client secret as query parameters in the message to sign (but exclude the client secret in the actual request URL of course), or put the client ID in the Authorization header.

If anyone has a better way to do this, especially in a way that would still make it a valid OAuth 2 request, I'm all ears.

Regards
Steve

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 17 Mar 2011 16:03:38 +1100

Steve,

> ...
> I want to ensure that a user cannot use their own valid access token to make API calls from non-approved clients.
> ...

An app should be able to protect a MAC token secret almost as well as a client secret (perhaps even better as it isn't in the static code) -- as long as you are using HTTPS to issue it. A MAC token secret is not exposed to a casual user. Even a bearer token is not exposed to a casual user as long as you use HTTPS everywhere.

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Mar 2011 22:25:52 -0700

OAuth 2 intentionally dropped the use of client credentials when making protected resource requests. This seems to be your main issue.

If you are going to use MAC tokens, one easy solution is to tell your developers to simply concatenate the client secret with the token secret when signing the request. This is assuming the server has a way of mapping the token with the client on the backend. Basically, when you issue an access token, you only provide half the secret to the client. The other half is a prearranged value that is issued to the client OOB.

However, I am not sure how casual users are going to extract the access token issued to an application running on their mobile device (especially if you use MAC and obey they SSL requirement for getting the token). If anything, it should be easier to extract the client credentials from the code which is static.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Steve Hoeksema
> Sent: Wednesday, March 16, 2011 9:21 PM
> To: [email-masked]
> Subject: [OAUTH-WG] Method of validating client id & client secret for
> authenticated requests?
> 
> Hi all,
> 
> We have an API which will be consumed by approved native apps on mobile
> devices. For business reasons I want to ensure that a user cannot use their
> own valid access token to make API calls from non-approved clients.
> 
> Perhaps this is not what OAuth is designed to protect against, but I'd like to
> use a standardized authentication method if at all possible.
> 
> I understand the process of granting an access token to clients validated by
> client_id and client_secret, but I want to do the same for all authenticated
> requests.
> As far as I can tell, an an authenticated request is signed by an access token
> and token secret, but not client id and client secret.
> 
> I'm aware that determined users could extract the client ID and client secret
> from mobile app binaries, but this should stop casual users.
> 
> It might be possible to include the client ID and client secret as query
> parameters in the message to sign (but exclude the client secret in the actual
> request URL of course), or put the client ID in the Authorization header.
> 
> If anyone has a better way to do this, especially in a way that would still make
> it a valid OAuth 2 request, I'm all ears.
> 
> 
> Regards
> Steve
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth