1

I own a Javascript application (Single Page Application) hitting some apis from my own RESTful backend.

What I expect for my authentication/(authorization) mechanism is three things:

  • Preventing all known malicious ways of stealing or acting on user's data: CSRF, XSS etc..
  • Allowing only my Javascript official client to reach secured API of my backend.
  • Encrypting all the messages exchanged.

I'm not expert in security but I read some good articles about a guideline to follow:

  • Avoid an authentication way based ONLY on cookie mechanism, as this article well explains.
  • HTTPS is not enough, yet it is really really advise to ensure at least messages encryption.
  • Consider Javascript client as totally unsecured as its code is visible to anyone.

Of course, I agree with those principles but...I'm confused about the number of similar ways to achieve a good authentication mechanism:

  • What is the difference between the article I put in link just above and the OAuth 2.0 Resource Owner Password Credentials Flow?
    Indeed, both use those steps: exchanging username and password for an access token that is itself sent along the user's navigation using the HTTP Authorization Header.
    What additional security aspect does this OAuth 2.0 workflow bring compared to the cookie-based token solution?

  • Does the solution of cookie-based token as presented in the article is really enough to secure my infrastructure? As the author claims..

  • I came across this another great solution, that I judge also similar to others, excepted that it doesn't really need https since based on shared secret key: HMAC mechanism.

What would a security expert advise me? I don't exchange really sensitive data like money accounts etc.. but enough data to annoy users if something unexpected happens..

I would be happy to be more clear (in comments), but I hope I am.

I came across so many forums, articles, videos, etc... but I'm still confused about those different ways of achieving the thing.

Thanks

  • There's no way to ensure that only the JavaScript you wrote is hitting your backend. In fact, I'm going to guarantee that once the public gets access to the code, there'll be a hacked version. Note that even without source code being distributed game publishers have been failing at this for years, and JS distributes the source code... I'm not sure why you think HTTPS is "not enough" - Note that you'll need to distribute your JS application under HTTPS to ensure your client can trust it... Afterwards is a different story, but you'd need a similar style of encryption anyways, so... – Clockwork-Muse Apr 18 '14 at 13:41
  • @Clockwork-Muse When I evoke "HTTPS is not enough", I mean that a solution based ONLY on SSL activation is not enough to ensure a high security during authentication. Signature of requests should be handled additionally. – Mik378 Apr 18 '14 at 13:47
  • #scratches head# still confused there. What specific threats will HTTPS not solve for you? If you want a secure way to distribute your app from your website alone, you need HTTPS (for one or more portions of your site). Neither of the articles seems to argue that HTTPS is in any way insufficient. The HMAC article is essentially doing a related version of the protocol. You'd need to provide more details for me to get where you're headed with this. – Clockwork-Muse Apr 18 '14 at 14:03
  • @Clockwork-Muse I quote: "SSL is not enough. Some people thinking slapping an SSL certificate on a site automatically makes it secure and means they no longer need to worry about security. This isn’t the case. Man in the middle attacks, XSS, and CSRF attacks are all still possible when using SSL, especially during the initial handshake. Using SSL puts you pretty far ahead of the game but it’s not the end of the line." From here: billpatrianakos.me/blog/2013/09/12/… – Mik378 Apr 18 '14 at 14:13
  • Umm, the way most browsers deal with HTTPS/SSL is specifically designed to prevent MitM attacks. XSS and CSRF attack are unrelated to HTTPS/SSL (HTTPS/SSL simply encrypts the line, those attacks just give you something new to say). Unless you have tech-savvy users with out-of-band knowledge, you need a secure way to distribute (a bootstrappable portion of) your app - in current browsers, that's HTTPS/SSL. There's no way to prevent a client from mucking with his own key - although that may be rather pointless. All of that is to prevent the key leaking to other people. – Clockwork-Muse Apr 18 '14 at 14:44
2

The difference is : OAuth 2.0 is a standardized protocol, and there is many implementations in differents langages (JAVA, Python, PHP, JavaScript...etc) for both client and server sides. So you don't need to follow this article to implement something which "seems" similar to the OAuth 2.0 protocol and probably not secured.

For the cookie-based token solution : an attacker maybe can still a cookie from a logged (an authorized) user.

So, I think the best solution is to use the OAuth 2.0 protocol which already used by many corporations(facebook,twitter) for thier APIs

  • Even if I don't need a third party (as the essence of OAuth is to apply "delegation" not just "authentication"? Meaning, is OAuth 2.0 with only 2-legged worth? – Mik378 Apr 18 '14 at 11:27
  • 1
    Of course you don't need to separate the service provider and the authentification server, you can implemente both of them in the same server. – TMR_OS Apr 18 '14 at 13:22
  • Ok :) So let's go for OAuth 2.0 using Resource Owner Password Credentials Flow – Mik378 Apr 18 '14 at 13:31
  • 1
    Good luck Mik378 :) – TMR_OS Apr 18 '14 at 14:02

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.