Is the OWASP recommendation regarding localstorage still valid?
Personally I see no issue with using local storage as long as you are happy with the user not having to re-authenticate between sessions. The linked answer provides the following argument against this. I would argue it is very weak -
Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.
This applies with any kind of authentication token. Someone local with admin privileges (assuming its not encrypted with a key tied to the users credentials) can read it out of any kind of storage, RAM or maybe even straight off of the network.
He also suggests -
(or XSS flaw in the website)
Again - this applies to any kind of token that the JavaScript can access.
The reason local storage is considered unsafe is because any JavaScript that executes in the context of the page can access this. This opens you up to session hijacking via reflective XSS and stored XSS vulnerabilities, potentially information disclosure depending on the contents of your token.
For example: If a user goes to a page with shared content amongst other users and there is a stored XSS vulnerability another user can inject an attack that will steal your token from localstorage.
Short expiry only protects your token from replay attacks- but if a XSS vulnerability exists with access to localstorage this is going to have no affect on an active sessions as you can write a polling mechanism to extract the token from localstorage again on expiry
I suggest that you use a cookie as storage for your token.
- Cookies can be marked as HTTP only. This will prevent JavaScript from being able to access the cookie
- On the server have your code extract the token from the cookie and then validate it
- Also mark it for as Secure for HTTPS only
Sorry not enough points to respond so dropping this here:
Another consideration, what is your threat model? External attackers on the web: Store the token in a cookie process at the server Users on the same machine (Non admin): Maybe session storage so no persistance Local admin: Well nothing - they are local admin, they own the system
Client certification is not really a viable authentication piece for web applications as a user - MFA authenticators are the better alternative
Following the advices from the auth0 blog you can counter security concerns by keeping a low token expiration value and more importantly you can encrypt the token.
An alternative approach would be the use of JSON Web Tokens in association with OAuth2.