JWT login flow and token verification on server

Question

What is the proper way to verify a token on server?

I am using jwt token mechanism in my app and here's how its working as of now:

1. Client logs in with username and password
2. Server checks the username and password and creates token with RSA public and private key and sends a new token to client with payload containing users email address and then stores the same token in database.
3. Any subsequent requests for resources on server, client sends along jwt token Server then checks the token with token available in database based on email address a user is logged in with.
4. Then provides the resource to client.

I think I am missing something here. Reading other blog post, I see that token should be verified with secret key.

Few questions I have:

1. I am not sure whether token should be checked against public key or private key
2. While sending a jwt token to client do I have to send public key to client in payload as I am using RSA mechanism? So for each request for resource, I have to decode the token and check public key against private key?
3. And in which scenarios, I need to store token in database? or it is not required to store token in database at all?
4. What happens when a malicious gets hold of the token on client-side and use it for login?

Note: I am using vanilla java and jax-rs(rest) for back-end and angularjs for front-end. Thanks

Answer 1

1. Server must sign the JWT with private key. Then client can verify it using public key as well as Server itself when it receives a token back.
2. Public key must be known to the client prior sending a token.
3. You do not need to store access tokens in database since JWTs are signed. You can just verify it with the signature. If the token was generated using any other private key, it cannot be verified using your public key.
4. An attacker should not be able to log in using a Access Token. If there is a risk such that malicious gets hold of the token you must set a short expiry period for the token and use a refresh token for obtaining a new token. Refresh tokens should be persisted in server side. If a refresh token was compromised it can be invalidated (user should be able to revoke the access to that client). Alternatively you can inject a secure random number to the JWT and store that number in server side against a user. When user sends a token you must validate the secure random number in JWT against the one in database. Then you can invalidate the token by changing the secure random number in database.