Last night's OAuth Security Advisory 2009.1 was a little light on the details. The blog post wasn't much better. I was peripherally involved in the OAuth spec development and I couldn't work out what the advisory meant without a bunch of thinking and spec reading so I thought I'd try to explain it in simpler terms here.
For my example I'll use the real service Twitter and a theoretical service Twitten that lets users post to to Twitter in LOL-speak and authenticates via OAuth. Alice and Bob will be my attacker and victim.
Alice's normal authentication process goes like this:
- Alice loads twitten.com/login
- Twitten creates a regular HTTP session for Alice
- Twitten asks Twitter for an unauthorized token
- Twitten redirects Alice to an URL on the Twitter servers that will allow her to authorize the token
- Alice clicks OK to authorize the token
- Twitter redirects Alice back to Twitten
- Twitten exchanges its unauthorized token for an access token (associated with Alice's account) with Twitter and stores it in Alice's session
- Alice makes inane posts on Twitter via Twitten
- Alice loads twitten.com/login
- Twitten creates a regular HTTP session for Alice
- Twitten asks Twitter for an unauthorized token
- Twitten tells Alice what URL to go to to authorize the token, but she doesn't go there
- Alice tells Bob, "if you love Twitter and kittens try out Twitten - go to http://twitter.com/oauth/authorize/...." (the authorization URL from Twitten)
- Bob loads the authorization URL with his Twitter credentials and authorizes the token
- Twitten requests Twitter to exchange the unauthorized token for an access token (associated with Bob’s Twitter account) and stores it in Alice’s session
- Alice goes to twitten.com and posts "OMG PWNd" to Bob's twitter account
Update: changed wording to match Eran's suggestion, his blog post on the subject is excellent reading.