Skylar's scenario is not valid even if only one client has the client credential, for the reason explained in my reply to Skylar, below.
Francisco --- On Thu, 3/31/11, Phil Hunt <phil.h...@oracle.com> wrote: From: Phil Hunt <phil.h...@oracle.com> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt To: fcore...@pomcor.com Cc: "Skylar Woodward" <sky...@kiva.org>, "OAuth WG" <oauth@ietf.org>, "Karen P. Lewison" <kplewi...@pomcor.com> Date: Thursday, March 31, 2011, 8:40 PM I have to agree. In OAuth, client credentials are dramatically weakened by the number of clients sharing the same credential. If the hacker has the same client with the same credentials (such as the case with mobile client apps), then use of client credentials when exchanging for an access token has minimal security value if any. However, if only one client can have the client credential, then it does add security value and Skylar's scenario may be valid. IMO using client credentials alone is insufficient to validate a particular client instances right to use an authorization code that could be leaked. I have been pushing the TLS thing for several days on the list, and I agree there is strong push-back. Let's explore some other alternatives. What if we had some other means of positively linking specific requesting clients to a returned authorization token that does not rely solely on the client credential (since they are shared by multiple instances). This would help prevent an eavesdropper from hijacking an authorization. Would this be a better way to simplify? philphil.h...@oracle.com On 2011-03-31, at 1:06 PM, Francisco Corella wrote: Skylar, > So, imagine a website secured inside a corporate > firewall. This service needs to access the provider's > services via OAuth and thus exposes one callback open to the > world for purposes of the OAuth handshake. The redirect URI > is HTTP since the corporation is having trouble acquiring or > setting up a certificate for HTTPS - in any case, the > provider does not requrire it. In this case, the auth code > flows into the firewall via HTTP, but is further validated > by client credentials over TLS in access token > requests. Valid tokens return to the web application inside > the corporate firewall over TLS and the information is still > secure from outside threats. So, my point is that the use of > client credentials (always kept secret and inside the > firewall) secures the auth code exchange and use of HTTP > doesn't create a vulnerability. That is simply not true. CLIENT CREDENTIALS DON'T HELP. If the user is outside the firewall and the callback URI is not protected by TLS, the attacker intercepts the authorization code outside the firewall and submits it to the client through the firewall. The client exchanges it for the access token, uses the access token to get protected resources, and sends those resources to the attacker outside the firewall. Francisco
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
