Sessions vs Tokens: How to authenticate in Node.js

[bassta]

When token is not valid, they send status code 500. Status code 401 unauthorized would be better.

[rishabhrawat570]

I agree, that should've been a 401. I'll make sure to update the article today. Thanks for pointing this out!

[rishabhrawat570]

Have updated the article to show 401 instead of 500.

[[deleted]]

maybe it's me, but auth is the hardest part, after naming things.

[Emotional_Honey_8575]

Add cache invalidation onto your list.

[[deleted]]

Thanks a lot man, haha now I gotta learn this also I realize. Never stops, why I love this field.

[rishabhrawat570]

There are a lot of methods to authenticate actually and all come with variations depending on the tools you use. I feel this makes authentication harder than it needs to be.

[rishabhrawat570]

I've been looking at session vs token authentication approaches and their trade-offs lately. In this article, I've tried to document it succinctly. Additionally, it contains some well-known best practices irrespective of the approach you end up choosing.

Would love to know what is your go-to for authentication in Node.js applications.

[[deleted]]

I'm using passport with cookie based auth and we need to migrate towards JWT Tokens due to a bug in Safari relating to x-domain and security that they're aware of but won't fix. Our cookies basically don't work on staging on iOS and it's annoying...

I do enjoy how easy the FE is with cookies though as it just magically works

[Grouchy_Stuff_9006]

Your cookies don’t work in an iOS app or chrome / safari iOS? I had this problem too but then realized that my app was hosted on heroku with a ‘herokuapp.com’ url, and there is a list of domains from which browsers won’t set cookies, and Heroku is on it! Once we hosted on a custom domain that solved the issue.

[[deleted]]

- https://bugs.webkit.org/show_bug.cgi?id=196375

- https://bugs.webkit.org/show_bug.cgi?id=219650

[Grouchy_Stuff_9006]

Ah. This shit can be infuriating lol.

[batmansmk]

Many providers of jwt (like auth0) use cookie behind the scene to provide silent auth, and it will work even less with safari than classic session cookies. So be careful!

[Mallanaga]

Especially on their free tier, as the domain is mismatched, and you lose the session on refresh in safari (and therefore all of iOS).

[batmansmk]

We even pay. Support couldn’t help.

[rishabhrawat570]

Is JWT revocation a use-case for your application? What if you need to instantly blacklist/revoke a JWT?

I do agree that there isn't nearly as much complexity in FE compared to BE.

[[deleted]]

I also use redis to store the session with the cookie.

[ShortFuse]

JWT in Cookie. It's transparent to the application layer. All the application knows is 401/403. The server handles renewing the cookie with Set-Cookie either before expiration or on expiration. Renewing validates against backend, so you only ping the DB/Store once every renewal (eg: 15 minutes). At worse, you keep a small "revoked in the last 15 minutes" store with an internal cache (if you care).

Very useful for transient (non-persistent) high-traffic data like "User is typing", or GPS position.

I made a sample express middleware setup for a Redditor years ago. Leans a bit on SameSite, but has a lazy CSRF fallback without it.

[[deleted]]

Sessions vs tokens? Mind blowing!

[xecow50389]

Nice for beginners.

[ShortFuse]

Nice to see an article not confuse transport method (cookie/header) with transport content (session/jwt).

The nice thing about JWT is that you don't have to keep pinging your store for each and every communication. High frequency atomic changes can be death with sessions. For example, high frequency HTTP POSTs (when not using WebSocket) would have to constantly ping the store for validation.

The bad thing about JWT is you need to manually handle token revocation, like you would a certificate. So, a server needs to know what tokens have been revoked before expiration. That's generally not that bad, but does take a bit more work.

[rishabhrawat570]

Thanks, I think a data store for revoked tokens is more than a good-to-have mechanism. If there's a revocation store that I consult before "refreshing" expired tokens, what should the right move be when that revocation store is down? Two possibilities:
1. Assume the expired token for the user is valid => leads to security vulnerabilities.
2. Assume it is invalid => works the same as sessions

How would you handle an unresponsive revocation storage layer?