Use cookies and sessions (not JWTs) for authentication

Re:Use cookies and sessions (not JWTs) for authentication by thinkingkong on Sunday January 15, 2023 @10:51PM (#34396585)

I think the original motivation was tied to when people were trying to build unified APIs for every kind of client: web, mobile, m2m. Cookies and sessions werent always available afaik.

[ Parent | on HN ]

Re:Use cookies and sessions (not JWTs) for authentication by TobyTheDog123 on Sunday January 15, 2023 @11:11PM (#34396699)

I was under the impression sessions were just arbitrary tokens backed by some server-side logic (or perhaps a database)

At its core isn't it possible to just take an object, encrypt it with a secret, store it client-side somewhere (cookies, localstorage, filesystem, printed-on-paper, whatever), send it back to the server, and it decrypts it?

I don't quite see the difference (or benefits) of JWTs over something like that.

[ Parent | on HN ]

Re:Use cookies and sessions (not JWTs) for authentication by joshuaavalon on Sunday January 15, 2023 @11:23PM (#34396781)

The difference between JWT and session is where the state is stored.

For session, you need a centralized backend to access the data stored in the session. For JWT, you only need to verify the signature of the token to trust the data stored in JWT.

JWT solves the problem of having multiple separated service that need to share data.

[ Parent | on HN ]

Re:Use cookies and sessions (not JWTs) for authentication by zulvkr on Monday January 16, 2023 @01:29AM (#34397518)

Storing state in JWT is easy way to share state, such as user permission, between different server.

But state in JWT can be outdated due to permission changes and you it's not possible to just expire it as it's stored in client.

To solve the problem, more complex auth setup is needed such as using short lived JWT, refresh token, which feels more like a bandaid to make JWT sufficiently secure

[ Parent | on HN ]