(The previous thread is became completely inaccessible to anyone not following it carefully for the past week or so. For the sake of reaching a conclusion, I am going to sum up the issue and try to start over with a more narrow focus.)
* The security issue is very simple: The authorization code is the only artifact binding the resource owner granting access at the authorization endpoint to the resource owner being redirected back to the client. OAuth 1.0a added the verification code for this sole purpose. If the authorization code is intercepted by a MITM (e.g. fake airport wifi), the attacker can take over the session and pretend to be the real resource owner. Since the client has no way to detect this, it will grant the attacker access to the client application which usually includes data obtain via the access token (received using the compromise authorization code). The attack does not give the attacker any direct access to the access token, the client credentials, or anything other than the client application itself. However, the client application is typically considered an extension of the resource server. Another variation of this attack is related to the implicit grant (user-agent flow). If a MITM can intercept the response in figure 4 step E, it can manipulate the script to obtain the access token (and any secret or other properties is included). In other words, the client redirection URI must use a secure channel to completely prevent these issues. However, it is important to note that this is not OAuth specific. It is a general security concern regarding all other aspects of the client if it is not fully secure. For example, if the client uses insecure cookies or provides authentication via other means not using TLS. If the client is insecure, well, it's insecure including its OAuth redirection endpoint. * The two solutions The debate is which of the following two language alternative we want to include in the specification: 1. Include a normative MUST use TLS for the client redirection URI endpoint. 2. Include a normative SHOULD use TLS for the client redirection URI endpoint with strong language explaining the various attacks possible if the endpoint is not made secure. Both options reflect the same security issue, but *communicate* the *same* solution differently. Since this is just a specification (no standard police), this is just a manual, not an actual defense. --- You can stop reading here if you are short on time. This should give you all the information you need to know --- * The difficulty There is no debate that this is a valid security concern, and that the only solution is to apply a MITM protection (i.e. TLS). However, given the current web landscape and OAuth history (or any other web API), requiring TLS is an unexpected change to the *ecosystem*. From unofficial discussions I had with Yahoo!, Facebook, and Google today, all three indicated they have no plans to enforce such a restriction. None of the major OAuth 1.0 providers today enforce such a requirement, even though the exact same issue is present in OAuth 1.0a. The challenge is to find the right *language* balance between reflecting reality and reflecting the ideal security configuration. This is not a question of what is appropriate in certain situation, or the unique attack vectors of individual deployments. It is about how we talk about security, and how to best push the web towards better security without pushing too hard too fast. To me, the challenge is how to effectively communicate the issue, without forcing companies to knowingly violate the specification. The problem with that is that experience shows it's a slippery slope. Once you are no longer fully compliant, it is easier to let other MUSTs slide. In the consumer web space - which originated and is still the primary audience for this work (no matter how much the enterprise folks here protest) - enforcing such a requirement on client developers is impractical. Very few providers can afford to alienate their developers by making such a requirement today. It will also completely undo all the other work done to make this specification more accessible and easier to deploy. Hands down, deploying server-side TLS is much harder for client developers than figuring OAuth 1.0 signatures. EHL
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
