I go with JWT, because for every sessionID i want to hit database which is costly and time consuming.
Yes there is no way to revoke the jwt once it is issued.
This problem can be rectified if you can store the token in redis or any other mem-cached database. To verify the token fetch token from mem-cached database and verify it. to revoke just remove the token from redis.
You can store any information you want in the Claims of a Token. Given this, it is trivial to revoke the Token. It's the exact same mechanism as revoking a Session ID.
SessionIDs can be blazing fast if you hookup Redis to it, mitigating the complexities of jwt blacklisting. Blacklisting tokens is the inverse of storing SessionIDs, you could end up with a huge list of blacklisted tokens.
Also, jwt payloads are much bigger then transporting SessionIDs. Use case dependent factors to keep in mind.
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 go with JWT, because for every sessionID i want to hit database which is costly and time consuming.
Yes there is no way to revoke the jwt once it is issued.
This problem can be rectified if you can store the token in redis or any other mem-cached database. To verify the token fetch token from mem-cached database and verify it. to revoke just remove the token from redis.
You can store any information you want in the Claims of a Token. Given this, it is trivial to revoke the Token. It's the exact same mechanism as revoking a Session ID.
SessionIDs can be blazing fast if you hookup Redis to it, mitigating the complexities of jwt blacklisting. Blacklisting tokens is the inverse of storing SessionIDs, you could end up with a huge list of blacklisted tokens.
Also, jwt payloads are much bigger then transporting SessionIDs. Use case dependent factors to keep in mind.