JWT for stateless API, but session control for security

Question

I really want to use JWT for API access, to keep it stateless. But at the same time I need to have strong security recourse to deny tokens that are yet to expire.

For more sensitive user information APIs I can rely on forcing a fresh login, comparing the IP address, etc. But I still want to be able to revoke a users token if needed. I don't mind paying the overhead price.

What I imagined would be to have each user create their own secret key based on their password, and store it in the session. I don't mind trading the overhead for an easier way to deal with stolen tokens. This way a simple password reset should invalidate old tokens.

Acknowledging the trade off, does this method make sense? Are there better ways to go about this?

Answer 1

JSON Web Token

JSON Web Token (JWT) is defined by the RFC 7519.

It's a standard method for representing claims securely between two parties. JWT is a self-contained token and enables you to store a user identifier, an expiration date and whatever you want (but don't store passwords) in a payload, which is a JSON encoded as Base64.

The payload can be read by the client and the integrity of the token can be easily checked by verifying its signature on the server.

Tracking your tokens

You won't need to persist JWT tokens if you don't need to track them.

Althought, by persisting the tokens, you will have the possibility of invalidating and revoking the access of them. To keep the track of JWT tokens, instead of persisting the whole token, you could persist the token identifier (the jti claim) and some metadata (the user you issued the token for, the expiration date, etc) if you need.

Your application can provide some functionality to revoke the tokens, but always consider revoking the tokens when the users change their password.

When persisting tokens, always consider removing the old ones in order to prevent your database from growing indefinitely.

Additional information

When sending sensitive data over the wire, your best friend is HTTPS and it protects your application against the man-in-the-middle attack.

To find some great resources to work with JWT, have a look at http://jwt.io.

Answer 2

I don't like the idea of white/black listing tokens, so I ended up using the users hashed password + another random key as their token's secret key:

+---------------+------------------------------------+-----------+
|     email     |              password              |    key    |
+---------------+------------------------------------+-----------+
| user@mail.com | asfsifj2fij4f4f4f8d9dfhs.8f8fhsd8h | r4nd0Mk3Y |
+---------------+------------------------------------+-----------+

I then keep a cache in memory of users id=>password+key to verify each users token. This way tokens can be discarded when: 1) user resets password; 2) application changes the user key.

This almost defeats the purpose of JWT's, but I need this layer of security for my use case.

Answer 3

You should create a "blacklist" on your server. If a token needs to be revoked, place it in the blacklist and set it to expire from the list when the token expires. For every authentication attempt, you will verify that the incoming JWT is not in the blacklist. Redis can make this quite easy.

Alternatively, consider a third-party service such as Stormpath. Disclaimer: I work for Stormpath. We have an Oauth2 api that let's you issue access + refresh tokens (for a password grant flow). We handle revocation for you, so long as you don't mind the overhead of the REST call to verify the state of the token. Please see Using Stormpath for OAuth 2.0 and Access/Refresh Token Management. We have easy support for this in our Express-Stormpath .library

Answer 4

well, i just had the same kind of implementation. add hashed password to token, and when client returns the token, during validation, check if user's password has been changed in db, if user's hashed pass is not the same as the one you put in token, reject the token. In this way, you don't need to keep any info about user and/or token on the server.