Re: [OAUTH-WG] What's the use case for signing OAuth 2.0 requests?

[Yaron Goland <[e-mail]>]

Relying on HTTPS -

                I would be interested in use cases where HTTPS isn't available but OAuth 1.0 signatures are a sufficient substitute. Also, HTTPS should be used with an application endpoint if it is dealing with high value content.

Bearer tokens and discovery -

                Unless an application endpoint requires a different access token for each URL then there must always be some kind of policy defining which application endpoints are willing to share tokens. So the issue isn't policy, it's what happens when a client screws up and sends a token some place they shouldn't have?

                In cases where an error is a real risk an easy solution to this problem that doesn't require signing the message is to use a proof of possession token. Just require that the OAuth token in the HTTP authorization header is a token signed/hmac'd with the proof-of-possession key where the audience is the application endpoint and the original access token is included as a claim.

                                Yaron

From: Eran Hammer-Lahav [mailto:[e-mail]]
Sent: Friday, September 24, 2010 7:44 PM
To: Yaron Goland; OAuth WG
Subject: Re: [OAUTH-WG] What's the use case for signing OAuth 2.0 requests?

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" <[e-mail]> 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