The default implementation of a JWT is stateless. That means you don't hold any information regarding the individual token in any form of storage (files, databases, memory, etc.). You're relying on the signature of the JWT to validate that you have issued this token.
This not more or less secure than a stateful token per se as far as protecting the token goes. It does however have security implications for a compromised token.
Since you have no way of knowing which individual token is due to not storing any information about them you cannot reject tokens which pass the basic signature validation. This means that if I somehow managed to acquire your token I will be able to pose as you until the token expires.
You can create a stateful JWT. Just store some data about it the token and in a database. Say a unique ID along with to whom it was issued. I've done a few different things over time with JWTs to keep them in good shape:
- Store the API version which issued it
- Store a password version of the user in it (meaning a password update revokes old tokens)
- Store a unique ID to identify individual tokens
For the record, revoking a token typically means outright removing the token information from your storage or marking it as deleted; as such it is rejected when authorization is attempted.
For the record I'm not saying that you need to add state to the token so long as you are aware of the implications. Personally I would add some state, not for myself but for the users. Security concerns is typically at the bottom of their list until something tragic happens.