3

I've implemented an OAuth 1.0 provider following this specification, which should be the latest. The specification was amended to address the session fixation attack that was identified in 2009. The thing is, short of having to diff the two specifications I am unsure as to what measures were added/changed in the spec in response to the issue.

Since I implemented the "right" spec I am having a hard time explaining to stakeholders what measures I have taken to ameliorate the risks.

Anyone care to shed some light on the issue for me?

Community
  • 1
  • 1
Jon Nylander
  • 8,743
  • 5
  • 34
  • 45

2 Answers2

5

1.0a addresses a very specific attack described here:

Explaining the OAuth Session Fixation Attack

Minh Nghĩa
  • 854
  • 1
  • 11
  • 28
Eran Hammer
  • 7,036
  • 3
  • 31
  • 23
  • The man himself answers! I've read that great post from top to bottom a couple of times, and I really understand the attack vector. However, I may be a little daft here - I cannot fully grasp what it is that has changed between 1.0 and 1.0a that addresses it. Is it the addition of the oauth_verifier? – Jon Nylander Jul 04 '11 at 07:14
  • Yep. To address the attack, we needed to add something that can bind the user authorizing access to the user retuning to the client. Note that the verifier acts as a bearer token and if it is captured by an attacker (a different vector), it can still take over the authentication grant (so use SSL/TLS for the client callback endpoint). – Eran Hammer Jul 06 '11 at 02:39
0
  1. The oauth_callback parameter is now required in the request token generation step. The oauth_callback_accepted response parameter indicated OAuth 1.0a is being used.
  2. The oauth_verifier parameter is generated by the service provider during the authentication/consent phase.
  3. The oauth_verifier must be sent at the access token generation step.

See http://wiki.oauth.net/w/page/12238555/Signed%20Callback%20URLs for more details.

Alex Smolen
  • 11
  • 4