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