I am sorry for sounding harsh, but everything written here is highly misleading and extremely dangerous. I would plead with the author to do more research and update the contents of the article. No, session tokens should not be used today under any circumstances unless the developer is lazy or have not caught up on basics of web security in the past decade. And no, it is completely false that JWTs do not have expiration. It is actually their main feature that made the popular. On top of it the same token allows to take care of both authorization and authentication which is a very nice add-on. Furthermore, there are established procedures for token revocation, and JWT allows for seamless horizontal scaling. Short-lived token auth with automatic token update on every API call is the only secure way to battle intercept or leaking of auth info because it invalidates the token on the next response. Refresh tokens are what is used to allow long-term access to the resources and storing those requires extra care. All of it is well established and formalized in OAUTH 2.0 standard en.m.wikipedia.org/wiki/OAuth
I agree with you. I think it would also be good to elaborate on Refresh Token purpose in your response. As you know, the Refresh Token is used to separate the responsibility of access revocation from the 'resource provider' and put it back on to the authorisation server / identity provider, where it belongs. If somebody loses their mobile device and wants to revoke access, this can be done by notifying the identity/auth provider, who revokes the refresh token. The backend API providing the resources cannot easily do that without for example either maintaining its own access logic (overlap of responsibility with auth provider) or revoking signing keys (invalidates all other access tokens too). I think this knowledge is implicit in what you write but would be best made explicit.
PS JWT do not need to be ever stored in any DB as they provide stateless access and we just beed to verify signature, so no, nothing like session tokens
Then start elaborating yourself. Why session tokens shouldn’t be used? The point I see that OP made is actually fantastic. There is no advantage in using JWT over session based auth for simpler architectures. The whole implementation of stateless token authentication seems miles more complex in comparison with session based auth. The whole internet cannot agree whether access tokens should be stored in cookies or local storage, then it cannot agree whether the token should be stored/blacklisted server side or not, then how refresh tokens should be stored. Not storing JWT access token server side makes it hard for immediate invalidation which then, makes JWT way less safer than session.
Errr, jwt shouldn't be stored neither in cookie or localstorage. They should be stored in memory (there's no perfect solution though, even cookies are vulnerable to csrf)
You should never need to invalidate jwts immediately, they should expire fast (a few minutes). To invalidate logins instantly there are a number of ways to do it. My favorite is an in validation marker. Any token with expiration date after an in validation marker will be rejected alongside any attached refresh token thus forcing the user to authenticate again.
You should never need to carry state in tokens. Tokens should help identify state for the backend.
Storing JWT access token in memory will make it vulnerable to XSS attacks. Fundamental of web security implementation is to presume that potential attacker knows how your implementation works. Storing access token in a cookie with httpOnly flag is a way to go. JS is unable to access httpOnly cookie. JWT indeed cannot be invalidated immediately without persisting some state which indicates that the token is invalidated or by rotating secret key used for its signing.
Actually it's about the same. Nobody needs to "get" your token. Cookies are being sent on client side requests. Xss doesn't need to read your token, it needs to make requests on your behalf and can do so if your token is stored in cookie.
No, session tokens should not be used today under any circumstances unless the developer is lazy or have not caught up on basics of web security in the past decade.
According to whom? Session tokens aren’t inherently insecure even if some implementations are.
And no, it is completely false that JWTs do not have expiration. It is actually their main feature that made the popular.
Nobody said they didn’t? He stated in the article that they have an expiry. The issue he’s illustrating is that you either have to choose between longer expiry durations (which is less secure and means you cannot manually expire the tokens) OR setting short expiry durations and essentially having little to no benefit over a session token because you have to access the refresh token and then generate a new JWT.
Short-lived token auth with automatic token update on every API call is the only secure way to battle intercept or leaking of auth info because it invalidates the token on the next response.
Well this is patently false. It’s ‘secure enough’ but so are many session token implementations - and they’ve been industry tested and used without fault. Short-lived tokens are still prone to their own security flaws such as the refresh token being leaked and at some point you’re going to have to exchange your shared secret or refresh token.
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 am sorry for sounding harsh, but everything written here is highly misleading and extremely dangerous. I would plead with the author to do more research and update the contents of the article. No, session tokens should not be used today under any circumstances unless the developer is lazy or have not caught up on basics of web security in the past decade. And no, it is completely false that JWTs do not have expiration. It is actually their main feature that made the popular. On top of it the same token allows to take care of both authorization and authentication which is a very nice add-on. Furthermore, there are established procedures for token revocation, and JWT allows for seamless horizontal scaling. Short-lived token auth with automatic token update on every API call is the only secure way to battle intercept or leaking of auth info because it invalidates the token on the next response. Refresh tokens are what is used to allow long-term access to the resources and storing those requires extra care. All of it is well established and formalized in OAUTH 2.0 standard
en.m.wikipedia.org/wiki/OAuth
I agree with you. I think it would also be good to elaborate on Refresh Token purpose in your response. As you know, the Refresh Token is used to separate the responsibility of access revocation from the 'resource provider' and put it back on to the authorisation server / identity provider, where it belongs. If somebody loses their mobile device and wants to revoke access, this can be done by notifying the identity/auth provider, who revokes the refresh token. The backend API providing the resources cannot easily do that without for example either maintaining its own access logic (overlap of responsibility with auth provider) or revoking signing keys (invalidates all other access tokens too). I think this knowledge is implicit in what you write but would be best made explicit.
PS JWT do not need to be ever stored in any DB as they provide stateless access and we just beed to verify signature, so no, nothing like session tokens
Any chance you could produce a counter post.
The author didn't say JWT tokens were to be stored in a database, that was in context of a refresh token.
Maybe putting an article together to tackle the actual content of this one will help everyone be clearer on what is the correct process and why.
Then start elaborating yourself. Why session tokens shouldn’t be used? The point I see that OP made is actually fantastic. There is no advantage in using JWT over session based auth for simpler architectures. The whole implementation of stateless token authentication seems miles more complex in comparison with session based auth. The whole internet cannot agree whether access tokens should be stored in cookies or local storage, then it cannot agree whether the token should be stored/blacklisted server side or not, then how refresh tokens should be stored. Not storing JWT access token server side makes it hard for immediate invalidation which then, makes JWT way less safer than session.
Errr, jwt shouldn't be stored neither in cookie or localstorage. They should be stored in memory (there's no perfect solution though, even cookies are vulnerable to csrf)
You should never need to invalidate jwts immediately, they should expire fast (a few minutes). To invalidate logins instantly there are a number of ways to do it. My favorite is an in validation marker. Any token with expiration date after an in validation marker will be rejected alongside any attached refresh token thus forcing the user to authenticate again.
You should never need to carry state in tokens. Tokens should help identify state for the backend.
Storing JWT access token in memory will make it vulnerable to XSS attacks. Fundamental of web security implementation is to presume that potential attacker knows how your implementation works. Storing access token in a cookie with httpOnly flag is a way to go. JS is unable to access httpOnly cookie. JWT indeed cannot be invalidated immediately without persisting some state which indicates that the token is invalidated or by rotating secret key used for its signing.
Actually it's about the same. Nobody needs to "get" your token. Cookies are being sent on client side requests. Xss doesn't need to read your token, it needs to make requests on your behalf and can do so if your token is stored in cookie.
According to whom? Session tokens aren’t inherently insecure even if some implementations are.
Nobody said they didn’t? He stated in the article that they have an expiry. The issue he’s illustrating is that you either have to choose between longer expiry durations (which is less secure and means you cannot manually expire the tokens) OR setting short expiry durations and essentially having little to no benefit over a session token because you have to access the refresh token and then generate a new JWT.
Well this is patently false. It’s ‘secure enough’ but so are many session token implementations - and they’ve been industry tested and used without fault. Short-lived tokens are still prone to their own security flaws such as the refresh token being leaked and at some point you’re going to have to exchange your shared secret or refresh token.