These are my two: 1. Remove the need to rely solely on HTTPS
There are plenty of cases where people can't or don't want to use HTTPS. Clearly, the web is not all HTTPS and OAuth should be useful on the entire web. We are not going to settle the long debate over the cost or speed of using HTTPS. It doesn't matter. There are enough people who are set in their mind about it and we need to offer an alternative. >From an implementation perspective, HTTP client implementations are >notoriously broken. Not the library code, but the way developers use it. For >example, most developer ignore exceptions about invalid or expired >certificates. This is why the major browsers had to change their UI to make it >really hard for users to accept bad certificated (which people still do). We >keep forgetting that while HTTPS is properly executed in most browsers, it is >not the case in most client applications. I would like to see a detailed section in the specification detailing everything a developer has to check to actually ensure their HTTPS connection is secure and to the right destination. It is nice to put the burden on HTTPS and point people there, but if we know they are going to do stupid things (like they have done before), we have the responsibility to write a defensive protocol that prevents exploits when developers make predictable mistakes. Another aspect of HTTPS is that in most cases, it terminates at the entry point to the server deployment which exposes the tokens internally to anyone with access, beyond the final applications. *** If HTTPS is to remain optional for protected resource requests, a signature-based alternative is required. 2. Ensure that tokens are not open to phishing attacks Discovery as well as future use cases for OAuth will create the need for clients to authenticate using tokens against servers that are not hard-coded into the application. When this happens, bearer tokens are simply too dangerous. Any solution that is based on sending secrets in the clear (that is, whoever receives them on the other side can use them, legally or not) is going to cause secrets to leak. I don't need to lay out the exact exploit, only to point to the past 20 years and show that every single password-based solution has been proven broken, even when used over secure channels. It is sad that some of the people who criticized WRAP for this exact reason are not taking part of this discussion and gave up (some due to lack of time or interest, others due to being told to STFU by their employer). It is true that there are methods for using bearer tokens with discovery, but those I have seen all require the client to basically ask the server after each new resource they encounter if it is ok to send the token there. This is very inefficient, when a signature solves that (as offered successfully by OpenID). The other solution is to tell the client using some form of policy where it is ok to send tokens (as is done with cookies), and that's clearly an approach guaranteed to fail. EHL On 9/24/10 2:18 PM, "Yaron Goland" <yar...@microsoft.com> wrote: My understanding of Eran's article (http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/) is that Eran believes that bearer tokens are not good enough as a security mechanism because they allow for replay attacks in discovery style scenarios. He then, if I understood the article correctly, argues that the solution to the replay attack is to sign OAuth 2.0 requests. In http://www.goland.org/bearer-tokens-discovery-and-oauth-2-0/ I tried to demonstrate that in fact one can easily prevent replay attacks in discovery scenarios using OAuth 2.0 and bearer tokens. If the article is correct then it is not a requirement to introduce message signing into OAuth 2.0 in order to prevent the attacks that Eran identified. So this leaves me wondering, what's the critical scenario that can't be met unless we use sign OAuth 2.0 requests? Thanks, Yaron
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
