Ensuring user authentication and protecting an on-going session are vital parts of modern web development. Among the many options for managing auth...
For further actions, you may consider blocking this person and/or reporting abuse
Stateless JWT and Token revocation contradicts each other.
How so?
JWTs aren’t ever truly stateless; the
iatandexpclaims provide a window of time during which the token may be considered valid. That’s state. Revocation lists allow for the token to marked as invalid even before it expires. The longer the validity window, the more important it is to have a means to mark the token invaild.The server has to look for the token in some database to see if it's blacklisted. It means that verification cannot be stateless and based on the token itself only.
"Stateless" in this context means that the server does not have to keep any server storage and look up tokens
Ok, we share some understanding. If you need to invalidate a token before it expires (the likelihood of which increases with the length of time the token is valid for), then you are going to need to perform some sort of lookup as part of validating the token. A database lookup could be one option. A bloom filter is another. You could also just keep the lifetime of the tokens very short (say, 5 minutes) and accept the trade off of clients needing to obtain a new token more frequently in exchange for reducing the risk of the window of time during which the token can be stolen and used illegitimately.
I often hear this about JWT, make sure it's stateless and maintain a blacklist/revocation list, which are totally contradicting terms, you can't have both. The overhead of abandoning stateless is typically extremely small, so don't even go that route unless required.
There are situations where stateless is the ONLY way possible, for example, if you're calling something that doesn't have access to the database, like a 3rd party service or microservice with no database. That's where stateless is useful. But, if this is (for example) an API service that has database access anyway, just abandon the stateless "feature" of JWT, as you'll probably need to validate the token anyway (with a blacklist), so some type of database access will be required anyway.
short explain: In scenarios where you need to authenticate to a service that doesn’t have direct access to your user database, JWTs are ideal because they can be validated by the service independently as long as it has the right key or public key to verify the token’s signature.
In a microservices architecture, services often need to authenticate requests from other services or components. Since each microservice can validate the token by itself, there's no need for a centralized session store or database lookups.
What they mean is server side state. It's impossible to validate jwts allowing for revocations without checking server state.
The main benefit of jwts is authentication without server state. If you want to allow revocation you lose that benefit.
Being stateless is just one feature of JWT, and it can be very useful when you're talking with a service that doesn't have database access to validate access. This is where the stateless feature shines. For example, you can create a very short-lived token (like 30 seconds) to sign on to a 3rd party service that doesn't have access to your database. But if you have database access, just abandon the stateless feature, as the overhead is small to access the database, and you should be anyway to makes sure the token isn't on a blacklist.
The server uses the information encoded within the token to identify the user and doesn't keep any session information on the server. This is the typical usage of JWT. Even though JWT is designed to be stateless, you can implement a stateful mechanism (like token blacklisting) by storing the token's identifier in a database and checking it on each request to ensure it hasn't been revoked.
The suggestion to abandon the stateless nature of JWT if you have database access oversimplifies the situation. Even if you have database access, the stateless nature of JWT can still provide benefits, such as reducing the frequency and load of database queries for authentication and authorization, thus improving performance and scalability.
Depends on how you implement it. There is a pretty common design pattern of using issuing two JWTs at login. One a short lived access token and the other a long lived refresh token. You can store the refresh token in a database and validate against it. The refresh token can only be used to issue new access tokens and not access other APIs. So your access token is still stateless. And you can easily revoke the refresh token by deleting it from the database.
No. It quite simple to implement. You just need to keep revoked tokens in DB or in-memory cache (like Redis), removing it when expire. It had better to implement this check at API Gateway layer to avoid each service perform the revocation check.
Am not seeing how you are verifying identity here. How is this mastering? Be a little more elaborate please.
Using JWT for session management is a gross misappropriation of the technology. This has been pointed out countless times, in write-ups as well as the comments on this post, so I'm not going to reiterate here. If you're unable to understand the fundamental contradictons that inevitably arise, there's ample material available to educate yourself. If you still don't understand and publish articles about "mastering" something that is a fundamental mismatch, you should rethink your career choices. And no, the fact that even popular frameworks use JWT doesn't make it any better.
You keep stateless but in another hand you want revocation, it's contradict
I dig it. I think it's essential to sign JWTs in order to maintain the integrity of the token. This is a decent write-up, thank you!
The term "stateless" in the context of JWT (JSON Web Tokens) refers to the characteristic that the token itself contains all the necessary information to validate the session or request
Unlike traditional session management, which often stores session information on the server (like in a database or memory), JWT does not require the server to keep session state. The server decodes and validates the token using a secret key or a public/private key pair