Right, but just so we are clear, the only case you are discussing here is the MITM attack, which George, I and others have recently outlined.
I'm not outright opposed to the language requiring TLS for the redirect URI, but the consequence is that some providers may need to find workarounds or (breaking?) exceptions to this rule. In reality the OAuth process will be much more paranoid than most provider websites serving the same information, but for the purposes of the spec, it's not necessarily a bad thing. It just means some people might need to bend the rules to serve there customers until all of the web gets to a higher level TSL competency and dependence on signature authorities. So, if MITM is the only attack then for this case, we're sure that all other aspects of the exchange are similarly protected from MITM as well? I think for some providers, the risk of MITM in this case will be so low as to not trump the value of the data protected (or the availability of that data through other or more cost-effective means). Still it doesn't mean the OAuth spec has to settle for less - we had the same argument around Bearer tokens. In the worst case, clients unable to set up HTTPS endpoints could be forced to require OOB flows (where the auth code must be manually transferred by the user from the provider into the client app) if they still wanted a fully spec-complient deployment. skylar On Mar 31, 2011, at 4: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
