1

I have been reading a lot about not saving the tokens in the user agent storage and I agree with the risks mentioned. But going through some of the Auth0 quickstart examples, I see the tokens being saved in the session and using session cookies to track them.

Others mention saving the actual token as an httpOnly cookie with lower risks involved.

My questions are:

  • How is that considered stateless? especially with scalability and the potential use of load balancers.
  • Are the alternatives, memory cache and database stores? Is it that any different from sessions?
  • In the case of SPAs, how to maintain remember me functionality?
Wisam Naji
  • 35
  • 2
  • 6

2 Answers2

2

Asi Kavindu wrote, localStorage is a good place. If you want to protect the application against XSS attacks, use Content Security Policy, so a browser executes only your JavaScript code. There is a recent RFC about best practices for OAuth 2.0 and Browser-Based Apps, so you can check it.

If you want to keep state (session) on your backend with multiple backend nodes (cluster), you can use some shared data storage such as database or Hazelcast. The architecture is stateful in the same way as a single backend node with an in-memory session.

If you have a session on your backend and a cookie, you don't need an access token anymore, since yor SPA calls just your backend and the token would serve the same purpose as the session ID from the cookie.

The remember me functionality can be implemented using a cookie either at your authentication provider (probably better choice from the security standpoint) or your own application.

Architecture choices are usually trade-offs between simplicity and scalability. If you are just starting developing the application and not sure what to choose, I would go for simplicity, because even if you want to change it later, it should be easier to refactor.

Community
  • 1
  • 1
Ján Halaša
  • 8,167
  • 1
  • 36
  • 36
  • So this is actually what I am doing but then many raised concerns about using localStorage. Thank you for the detailed answers. – Wisam Naji Mar 16 '19 at 22:58
  • You can also use `sessionStorage`, which doesn't survive browser restarts and is reserved for a single browser tab. It can be more suitable if you want to store just short lived data and don't share them among browser tabs. – Ján Halaša Mar 17 '19 at 06:58
1

Maintaining a session is applicable only when there is a backend to your application. From purely SPA perspective, storing a token in localstorage is acceptable and relatively secure. Modern browsers have capability to protect loaclsotrage compared to other means.

If you have a backend, correlating access token to a session is better than storing it in a cookie. Also one advantage you get get with this is the ability to get a refresh token, which can be stored in backend.

Having a cookie means loosing statelessness. Cookies are there to maintain a state between server and client end. Session maintaining require server resources but I do not think you need to worry much on that. Scaling must be done targeting your specific requirement.

Remember me functionality is yet again something built with cookies. It is a functionality provided by authorisation server. Think it as your browser remembering your Facebook's logged in status. It uses cookies and your application does not have to worry on that .!

Kavindu Dodanduwa
  • 12,193
  • 3
  • 33
  • 46
  • 1
    My application is a SPA connecting to a backend API maintained by me too. I want the user to be remembered, I used to save his token in the localStorage. But now I am afraid of XSS which is why I am building a better auth server. If I use sessions then it will be locked to one instance in case I want to scale it. I will have to maintain sessions by using some memory or persistent DB. I was mainly looking for good architecture approach. – Wisam Naji Mar 15 '19 at 14:59