16

Is there any advantage to OAuth vs cookie-based sessions (established via username/password) under the following assumptions?

  1. There is only one legitimate client to the service
  2. The OAuth client secret has been compromised (so valid requests can be issued by anyone)
  3. The OAuth token and the session have the same lifetime
  4. Both allow access to the same set of resources with the same privileges
  5. All client-server communication under either scheme is via the same protocol (for arguments sake, HTTPS)
  6. The client and the server are controlled by the same party
13

Well, it depends...

OAuth is a protocol for creating a session. OAuth bearer tokens are transmitted by the client using the Authentication: Bearer HTTP header. This is just a cryptographic nonce that is transmitted via an http header element, which in effect is (almost) identical to the cookie http header element.

How does it differ? Well, the rules for cookies are a little different than other header elements. The cookie is maintained by the browser, and is attached to every request for which the cookie belongs. This is the reason why Cross-Site Request Forgery or session riding attacks work. The browser doesn't care where the request came from, it will attach the cookie based on the destination of the request.

OAuth Bearer tokens are a little different. These tokens are usually managed by the client (JavaScript, Flash, or even some middleware application). If your application uses JavaScript to manage the authentication bearer token, then this value will not be automatically applied by the browser, and therefore can double as a CSRF token, which is neat.

However, if you are using OAuth for middleware, then CSRF doesn't come into play, so it doesn't matter where it shows up in the header.

  • I'm not dealing with a browser-based client, so CSRF doesn't come into play. Seems like there's an equal vulnerability when it comes to session hijacking/OAuth token hijacking. – Michael Mior Sep 16 '12 at 21:55
  • I want to handle middleware authentication for both browser and non browser api calls.. For browser CSRF authentication, Non browser Oauth based authentication..Will it work? If possible how could i achieve this? – Tommy Jul 30 '15 at 7:16
  • 1
    CSRF is not a method of authentication, it is an attack. Consdier reading the OWASP top 10, espically the parts on session managment: (owasp.org/index.php/Session_Management_Cheat_Sheet). – rook Jul 30 '15 at 16:51
3

CSRF is already protected by all the modern browsers, if doesn't simply attach cookie based on destination, if validates allow origin policy before sending it to the server so to me after doing some research, oauth2 and session based authentication both have the same security risk and only difference is the header that is being used

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.