1

From what I understand, oauth2 does does not sign requests and relies on the security of the transport layer (over https). This seems to be vulnerable to both replay attacks and ssl proxy attacks where the certificate is not validated (which seems to be common amongst client apps).

In this sense it doesn't seem to be as secure as HMAC-sha256 or something along those lines. This may be fine for some apps, but for apps which move large amounts of money this doesn't seem like sufficient security. Am I understanding it correctly?

Brian Armstrong
  • 19,707
  • 17
  • 115
  • 144

1 Answers1

1

I would have to agree with you. For the most part, if you have a user doing activities that require a higher level of scrutiny (i.e. making payments), then you'd like to have a little more security and even some additional confirmation that it is indeed the correct user who is doing the activity. OAuth doesn't really provide that extra layer of security and I really wouldn't recommend it for payment activities.

Mark S.
  • 3,849
  • 4
  • 20
  • 22
  • Ok good to know. Thanks for the response. As for replay, I was thinking you could bolt a nonce param on to regular oauth2 and check it server side. For the ssl proxy attack I'm not sure of any way to enforce certification validation server side though? That seems like the largest remaining vulnerability. – Brian Armstrong Aug 05 '12 at 19:38
  • Actually, this answer seems to suggest https is not vulnerable to replay attacks: http://stackoverflow.com/questions/2769992/replay-attacks-for-https-requests?rq=1 So maybe the cert validation is the real concern. I'm wondering if there are any companies who do a good job explaining this and helping clients validate certs in their api documentation. – Brian Armstrong Aug 05 '12 at 19:49