I just had the same problem by starting a web project while I am used to backend stuffs. There is lot of pro and cons for JWT, few cons but important ones for sessions...
Is there a third way ? Are we stuck between these two systems ?
I am really new to these front-side problems.
Probably there is, but do you really want to use it? Naha... I'm quite advocating for use of session based auth. since there are almost no benefits in usage of JWT's for monolithic or service layered architecture. Why so? Because, session based auth. is way easier to implement and mostly comes with already prebuilt libraries. Second, because you can still scale efficiently! Even if you store your session info in a database and take a look inside it upon each request to verify session validity, it will take like thousand requests per second until that becomes an issue. That's a huge scale already. Scrolling through the comment section, I noticed that people are sworn to some practices that are simply insecure. Such as, storing JWT in memory or local storage which makes it vulnerable to XSS attacks. Or persisting access tokens on server side which kills their whole benefit (you do the same for sessions). Someone will say: "But cookies for session based auth. are vulnerable to CSRF attacks!" (which can be solved rather easy). Token based auth. will also be vulnerable to CSRF attacks if you store access and refresh tokens in a right place on the client side - httpOnly cookie.
But to answer your question, what to use? If you have a monolithic or service layered architecture, feel free to go with session based auth. If you have a microservices architecture, a huge load and requirement for scaling, then you can simply have a dedicated authentication server (e.g. Keycloak) that issues JWT access and refresh tokens, and your microservices will remain fully stateless by just verifying JWT access tokens.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I just had the same problem by starting a web project while I am used to backend stuffs. There is lot of pro and cons for JWT, few cons but important ones for sessions...
Is there a third way ? Are we stuck between these two systems ?
I am really new to these front-side problems.
Probably there is, but do you really want to use it? Naha... I'm quite advocating for use of session based auth. since there are almost no benefits in usage of JWT's for monolithic or service layered architecture. Why so? Because, session based auth. is way easier to implement and mostly comes with already prebuilt libraries. Second, because you can still scale efficiently! Even if you store your session info in a database and take a look inside it upon each request to verify session validity, it will take like thousand requests per second until that becomes an issue. That's a huge scale already. Scrolling through the comment section, I noticed that people are sworn to some practices that are simply insecure. Such as, storing JWT in memory or local storage which makes it vulnerable to XSS attacks. Or persisting access tokens on server side which kills their whole benefit (you do the same for sessions). Someone will say: "But cookies for session based auth. are vulnerable to CSRF attacks!" (which can be solved rather easy). Token based auth. will also be vulnerable to CSRF attacks if you store access and refresh tokens in a right place on the client side - httpOnly cookie.
But to answer your question, what to use? If you have a monolithic or service layered architecture, feel free to go with session based auth. If you have a microservices architecture, a huge load and requirement for scaling, then you can simply have a dedicated authentication server (e.g. Keycloak) that issues JWT access and refresh tokens, and your microservices will remain fully stateless by just verifying JWT access tokens.