I actually have been a big fan of OAuth and its usage, until I didn’t read how it works, yesterday!
Let me say that, while offering some security, OAuth is not safe for work at all!
Read the article about at http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-attack/
This is not a small security hole, it’s a flaw by design!
So I read, that OAuth 2.0 is the next upcoming version of OAuth and already implemented e.g. by Facebooks Graph API and Github. However the draft is still under development.
UPDATE: After having read the OAuth v2.0 specification as far as I can see the problem has been resolved, cause the spec. requires now TLS for authorization requests and generates the token on the server and not on the client anymore, which however could be sniffed, if it wasn’t for the TLS mechanism.
So what’s the issue with OAuth 1.0 all about?
How OAuth authorization is working:
A consumer makes an authorization request to get access to the users data. (Actually he gets authorized to see some of the users data, not all). To enable this, the consumer therefore receives a so called request token, which then gets transformed in an access token + an access secret (all depending on the request token), which is not exchanged securely or over an encrypted channel, but just appended to the URL.
How it should be working:
The request token secret should be transmitted over a secure (encrypted with public key of provider) and authenticated (both sides know who is who) connection (similar to how the SSH Handshake works).
In fact the session fixation attack uses this flaw, in that:
In the authorization workflow, the user authenticates (“signs”) a request secret generated on the client and appended to a request URL, to be authenticated to access users data, which is ok under normal conditions, but the problem is, that an attacker can read in plain text, what the request token secret is (cause its not transmitted safely).
Substantially OAuth 1.0 is giving the master secret ~ request token to everyone.
Now even if a server developer limits the requests to only originate from the client(=consumer) an attacker can still hijack this mechanism by making a request “over” the consumer by using the request token and thus giving him access to the result of the request!
Note: although the request token is not the shared secret it directly “leads” to it, thus making it “equivalent” in many ways to the master key. Of course an attacker still has to go through the consumer site, which will do the calculations necessary to access the users data for him (request->access token secret) + signing (=hashing over consumer key and access token secrets), cause the attacker has none of them, and you could built infrastructure, thats lets this be done only by authenticated consumers. But even if consumers are authenticated, as you see, you can still go “through” the consumer and get out the users data!
Even worse with IP and domain poisoning, an attacker can trick the whole machinery (e.g. the service provider) into believing, he is the consumer and do the whole access key + hash calculations himself, thus even getting out access keys, etc.
This attack just wouldn’t work, if consumer and provider were authenticated to each other over a secure HTTPS channel.