JWT token login and logout

Question

Hi I am creating mobile native application that uses REST API endpoints to communicate with server side. I have had previous experience developing native clients, but I have simple token (random generated string) stored in DB in the same table where user information is stored. So it is like sessions used in browser, but instead of cookies each request has token in the header.

Recently I discoreved JWT token. It seems to be great way to secure endpoints which are private. You can request token from mobile client providing you pass + login and get generated token in response. But the one important thing is that this token is not stored anywhere on the server, server verifies the token using secret word, which is private for the server like private key. That's okay for secured endpoints, but what to do if I require user session, for example how do apps like Facebook, Amazon, Aliexpress ... work, they have ability to use the app without providing credentials, just navigating through the store, but require logining in when user want't to make purchase. And after that user session is kept for some time. This can be implemented with the JWT token without any problems, but when user need to logout, what to do in this case ? Token is not stored anywhere on the server, so how can I destroy this token, to make it invalid ?

If token is stored in the database, API is not stateless, as REST API should be. So in general there is no way to keep user logged in in stateless API, am I right ?

I have some ideas how to implement this using JWT token, but again this will not be stateless API, as I understand.

1. Create the list of expired tokens
2. Store JWT token in the database, but what is the purpose of self descriptive token (JWT) in this case if it is stored in the database, the main idea of JWT token to keep all information with token, as I know.

Please suggest what is the best way will be in this case, and correct me if I have mistaken. Thanks.

Answer 1

JWT tokens are primarily designed as an assertion mechanism i.e. provide the relevant user information to allow server to "know" the user on whose behalf operation is being performed. JWT is perfect for following scenario

1. You can not access user information on server side without user's involvement but you need some basic information for offline calls.
2. JIT provisioning i.e. to transfer user details from one site to another (aka federation).
3. Session/Stateless operation with limited data i.e. you need specific user data with each transaction but do not have concept of session (e.g. API, event processing system)

Even though it seems to be used for session, I think, it is not the best used for the same.

OAuth is more appropriate, I think, for session management. It is designed with basic concepts like refresh token (session extension in case of session expiry), access token (session id) which easily maps to session management concepts. In case of OAuth, authentication method (like JWT) is for server to decide. After that only thing client needs for the duration of session is an access token (similar to session id). The biggest issue I have seen being raised is that access token and refresh tokens need to be stored and managed on server. If you are easily able to map the access token to session id, I think you can remove that need. But given that you are already working on storing JWT, this should be a non-issue for you.

Answer 2

You are looking at a classic limitation of JWTs. They are not designed for session management. However, you can use them with some limitations (no logout, unless you use blacklisting, no idle timeout, etc...)

Ultimately you need to decide what is acceptable for your use-case. Let’s discuss the details.

how do apps like Facebook, Amazon, Aliexpress ... work,

The exact nature of their session management is unknown to me. I think they use stateful session management or a combination of the two to achieve their purpose.

but when user need to logout, what to do in this case ?

If you go JWT you need a way to blacklist the tokens which requires some state storage. This may be server side like you described or you may set up a dedicated service just for holding this state (this will leave your API stateless, but introduce complexity).

so how can I destroy this token, to make it invalid ?

You cannot destroy a JWT. It is possible to invalidate it by changing the signing key, however that will render ALL tokens invalid, that you the same key.

So in general there is no way to keep user logged in in stateless API, am I right ?

Being “logged-in” is a state that you need to store somewhere. If you outsource it to a service than it is possible for the API to stay stateless and support login and logout.

I have some ideas how to implement this using JWT token, but again this will not be stateless API, as I understand.

1. Create the list of expired tokens

This is called JWT blacklisting and it serves the purpose you described.

2. Store JWT token in the database, but what is the purpose of self descriptive token (JWT) in this case if it is stored in the database, the main idea of JWT token to keep all information with token, as I know.

You are right, this renders the self-describing capability nearly useless.

To sum it all up you need to decide whether you need the benefits of JWT. If so, can you live with its drawbacks? In my opinion, you should prefer stateful sessions in most cases.

In case you are interested in authentication alternatives, check out the web api authentication guide I put together.