1

I thought of a few approaches myself:

  • Use cookies. This requires CSRF protection and some logic complications as one needs to unify the cookie for both API and main domain. Also cookies seem a bit creepy regarding security overall
  • Render auth-related stuff on client. Well this would work but things as simple as the navbar, which should hide SignIn/SignUp buttons when authed, is auth related. With some overview of my existing application, SSR entirely looks pointless at that point.

What is the better approach to this? Something that's secure and practical?

Edit: I would highly appreciate a comment describing the reason for downvoting. I'm providing a bounty for a definitive answer that answers questions like this and this plus a lot of issues posted on GitHub and threads posted on different framework-specific forums.

OverCoder
  • 1,472
  • 23
  • 33
  • Have you seen [Superlogin](https://github.com/colinskow/superlogin)? – webnoob Dec 26 '17 at 22:27
  • @webnoob Reading the README, it looks like it doesn't mention anything related to Server-side rendering, no? – OverCoder Dec 26 '17 at 23:05
  • I was just offering it as a method of authentication after a quick glance at your question. Wasn't sure if it'd be useful or not :) The problem with SPA's is that you can't really rely on much because the client can change everything - obfuscation and minification will only slow them down. – webnoob Dec 27 '17 at 08:40
  • 1
    @webnoob That's why JWT is a thing. It can't be tampered by anyone other than you. Also, code obfuscation and minification has nothing to do with security, all it does is minimize network download, and no, it does not slow down software. – OverCoder Dec 27 '17 at 11:12
  • *them* == the user at decoding your app. Of course it doesn't slow the app down. – webnoob Dec 27 '17 at 11:16
  • @webnoob Oh, I misunderstood. Perhaps I will also use cookies because it looks like the only way to achieve authed SSR, even though I still find it a bad solution. – OverCoder Dec 27 '17 at 11:23
  • 1
    Care to elaborate on "Also cookies seem a bit creepy regarding security overall"? – godfrzero Jan 01 '18 at 04:42
  • Whole question is far too broad based on site guidelines in the [help] – charlietfl Jan 01 '18 at 21:31

1 Answers1

4

HTTP is stateless. You need to associate the client to the server somehow. The old standard method that assumes the client is dumb uses cookies for this association, which browsers automatically pass for you. It's still overall the most secure way of keeping the session - over HTTPs.

If you don't like cookies and you assume a smart client that can run code, then use tokens - preferably JWTs and place them in localstorage. Ensure you are running over HTTPs of course, and you still have to guard against XSS attacks.

That's all there is to it - head over to security.stackexchange.com to learn why trying anything custom is a bad idea.

kert
  • 2,161
  • 21
  • 22
  • 1
    Given a RESTful API, using sessions with cookies defeats the purpose. As far as I understand, JWT is a way to have an untampered claim held at the client. The problem is `localStorage` is not sent like cookies on the initial request, and thus it's not possibe to verify user authenticity on initial render request using such mechanism. – OverCoder Jan 02 '18 at 15:15
  • 1
    You have to go back to the fact that HTTP is a stateless protocol. `curl http://example.net` or opening up a blank browser will simply just not send any identification to the server, server won't know where it came from and cant tie it back to a user. The only working mechanism for associating a browser to a site on an initial request is cookies. – kert Jan 02 '18 at 16:56
  • 1
    If I login through an api call (creating a jwt), I can use this jwt in any ajax call to my site, but if I navigate to another page of my app by typing in the browser's address bar, then the jwt token will not be sent to the server. So even though I would have "logged in" to the site (experience-wise), I am not actually logged in (understandable since http is stateless). So how do we solve this problem? Going through the authentication process with an ajax call and then staying authenticated on page reloads/navigates? – Thanasis Ioannidis Sep 26 '18 at 12:50
  • Store your jwt token in localstorage. The new page you navigate to, that is still on your domain, can access it from there. And still authenticate API calls just like your last page did – kert Sep 26 '18 at 22:40
  • @kert so again it will not work for the first `GET` request to the server, only for ajax calls later, due `localStorage` is, well, local. – Mosh Feu Mar 13 '19 at 12:54