REST API authorization

Question

Let say you have a REST API, which you want to use as the backend for React application. The application supports user login. You use JWT authorization to make that REST API stateless. Now the problem I have with that is that the JWT expires after X minutes. Now my user have to perform the login again so he can browse the application.

I found a possible solution by using refresh tokens. Those should get another access token from the REST API after the previous access token expires. However, the refresh tokens also have expiration date. So the next option I found was to use some DB (for instance Redis) where I could store blacklisted tokens. But in the end of the day that is not stateless anymore. And what is the point of using blacklisting in that case why not use sessions?

There is a lot of similar questions on stack overflow or blog posts etc. But normally people parrot the line that REST API should be stateless and you should NOT use sessions in it - and that the JWT is the way to go. However on the other side a lot of posts also mentions that you should not use JWT-s for anything related to session management. However they never provide the alternative or "best practice".

So my questions are (I am mainly interested in question 3):

1. how can you authorize the user to call REST API-s functions and also that you have the option to REVOKE that access when for instance user logs out, or when user changes the password?
2. And if there is no way of managing sessions in the REST API, is REST API the right tool to use for my backend if I want to create for instance a mobile application and a website which consumes the same REST API?
3. What is the best practice for authorizing a user in the scenario where you have to deal with user log out in a REST API?

Answer 1

What is stateful?

There are different definitions of stateless. Formally, keeping JWT tokens in memory can be considered as a session. But usually JWT size is pretty small compared to the amount of business data that need to be processed by a user. That's why by a stateless application we usually mean that it doesn't use session to keep business data.

Distinguishing of security and business data is important. Some platforms like Spring, for stateful applications, do distinguish security session from web application session and use two different session IDs within each request.

Revocation of tokens

There are different approaches to revocation.

1. Check expiration date only. If the expiration date is not reached, the resource server considers the token as valid. Of course, we assume that the signature is valid. The validity duration is set to a relatively small period of time, e.g. 5 minutes. Advantage: This provides higher performance, because resource server does not need to call authentication server for each client request. Disadvantage: If an administrator grants or revokes some permissions, the old permissions can be valid until the token expired, because resource server can cache it for performance reasons.

2. Call authentication server for each client request. If signature is invalid or the token is expired, the resource server rejects the access. Otherwise calls authentication server to check if the token is still valid. Advantage: Any change of permissions has immediate effect. Disadvantage: Lower performance.

You can test in your particular case, if JWT validation has any effect on performance. E.g. it may be that calling authentication server to validate JWT takes 20 ms and execution of client request (accessing database, doing some computations) takes 1s, then you can ignore such performance effect.

Session management

It depends on platform that you use. For instance, in Spring there is session ID for security session. Independent on this, you can decide if you want the application to be stateless or stateful regarding business data.

About best practice

Architecture depends on particular constraints that you have: Technology stack, costs, time, performance requirements, usability requirements, etc. That's why based on the information in the OP it is hard to say what approach can be optimal in your particular case. Here are just some questions that you may want to consider:

• How important is SSO? Depending on this also simple random string can be sufficient as authentication token.
• How many users should serve your application? If there are let say 1 000 users and it does not change essentially over the time, then stateful application may be a good approach.
• How important is high scalability? If important, stateless application can be a better choice.

One thing that is more or less generic: If you want to implement your own authentication just for fun, it is fine. But in case you are doing it for customers, the price of full and correct own implementation can be high, also security risks can be high. That's why a good practice is first to check if there are already solutions for your goal. For instance, if you want to fully manage authentication, you may consider Keycloak, in particular, it supports OAuth2 and JWT. If you want to provide "social login", you may consider OAuth2 based on Facebook, Twitter, Google, GitHub etc. Such ready solutions provide not only simple authentication, but also 2FA, password reset functionality.