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 protected] [mailto:[email protected]] On Behalf > Of Steve Hoeksema > Sent: Wednesday, March 16, 2011 9:21 PM > To: [email protected] > Subject: [OAUTH-WG] Method of validating client id & client secret for > authenticated requests? > > 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 > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
