The problem with JWT's is that they can't (easily) be revoked.
They're a signed signature, they don't have any feature to revoke them, nor would it be possible.
Furthermore, JWTs are easily decrypted. They're not an encrypted token, instead of a hash that can only be verified as being signed by the key/certificate. With that in mind, storing anything sensitive within a JWT is asking for trouble.
That being said, there are ways around that issue.
For example, wrapping a session/OAuth access token with a JWT token. Store, for example, the user id, application id and refresh token/identifier within the JWT's claims. Then when validating, you can remove any that are invalid JWTs (which will save database queries), and then just ensure the refresh hasn't been revoked every time. You can do a similar thing with sessions.
The problem with JWT's is that they can't (easily) be revoked.
They're a signed signature, they don't have any feature to revoke them, nor would it be possible.
Furthermore, JWTs are easily decrypted. They're not an encrypted token, instead of a hash that can only be verified as being signed by the key/certificate. With that in mind, storing anything sensitive within a JWT is asking for trouble.
That being said, there are ways around that issue.
For example, wrapping a session/OAuth access token with a JWT token. Store, for example, the user id, application id and refresh token/identifier within the JWT's claims. Then when validating, you can remove any that are invalid JWTs (which will save database queries), and then just ensure the refresh hasn't been revoked every time. You can do a similar thing with sessions.
Little nitpick - JWTs aren't made to be encrypted. There's a separate spec for JWT encryption.