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.
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
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