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:[email protected]]
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" <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
