Search code examples
oauth-2.0jwtauth0openid-connect

Tokens statelessness and storage


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?

Solution

  • 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.