In this tutorial, we will learn how to build a full stack Node.js Express + Angular 11 Authentication example. The back-end server uses Node.js Exp...
For further actions, you may consider blocking this person and/or reporting abuse
This is dangerous. The JWT should not be available to the client side code at all, let alone stored in SessionStorage.
The proper way is to set the JWT as a secure, http-only cookie that isn't accessible to the client code. It removes the need for the token storage service and interceptor, because the cookie is sent automatically, and it removes the chance of the token being stolen and someone impersonating your users.
Apart from XSS attacks, which are less likely to happen IMO if you're careful with the libraries you're using, what would be other downsides to storing the token in LocalStorage?
Also, if you go with the cookie approach, you'll have to make sure that you prevent CSRF attacks from happening.
See my comment, for example session impersonation etc.
This is another example of a tutorial where it is fine for learning though not for learning how to do auth in production.
Please do not roll you're own auth in production. If you want to prototype something quickly then sure, roll your own auth, otherwise you should be using the defacto auth standard OpenID. Do not implement OpenID yourself there are a ton of providers and several good open source servers.
Do auth right, for your users sake.
Hi all, I've updated the project with HttpOnly Cookies for storing JWT:
Node Express + Angular: Authentication & Authorization example
Session impersonation, for example. In JWT approach, token is basically your session and can be used until expired. If you make it available to sites code, it becomes a target of any malicious script, browser extension etc. And if developer sets long expiration date, it becomes basically open door to your account if anyone intercepts it.
Where would that
malicious scriptcome from, assuming that the dev has done some research on the libs he/she is using and also that a modern framework is used. I'd say the same caution should be taken in the case of browsers extensions.The second problem can be mitigated by setting a short expiring date and adding a refresh token, which should last longer.
Supply chain attacks are getting more and more popular. It is not only about your project dependencies, their dependencies dependencies and so on. Even popular libraries can (and are) compromised.
Anyway, among security professionals there is a strong movement to restrict JWT to authentication and not as session tokens.
You may want to look at curity.io/resources/architect/api-... or other articles about JWT (in)security.
Makes sense. Thank you for sharing!
Man, I just came across your React Authentication articles and that reminded me of a project I was working on 2 years, where your tutorials helped me to implement user authentication properly in React and Node.js. As authentication evolves: have you ever worked with passkeys / WebAuthn. If yes, how do you see it compared to password-based authentication?
How can I test this code?
Well put together piece.
Solid pro & con talk in the comments.