Spring Boot JWT - How to implement Refresh Token and Logout REST-API

Question

We decided to switch from Basic-Auth to JWT because of the session-ids that were stored in the memory and which leads sometimes to over-memory consumption in shoot-down of our Spring-Boot server that serves an Android mobile app like Twitter.

But we have some questions about JWT for our mobile use-case:

• How long should an access token lives ?
• How long should the refresh token lives ?
• How to logout a User by invalidating his access-token and refresh token ? (For the logout we already delete the tokens on the mobile app side, but what if the tokens have being stolen by somebody and are still valid ?)

Answer 1

I will try to answer your queries

How long should an access token live?

You can easily configure expiry time so it depends on your requirement. In general, try to keep it short.

How long should the refresh token live?

Above goes for refresh token with a condition that refresh token generally lives longer than access token for obvious reasons.

How to logout a User by invalidating his access-token and refresh token? 

This part can be a little tricky.

You cannot manually expire a token after it has been created. So, you cannot log out with JWT on the server-side, as you do with sessions.

Can implement a few options like

• When a user performs logout action or compromised. Have a blacklist which stores invalid tokens until their initial expiry date. You will need to lookup DB for every request but storage should be less as you will be storing tokens that were between logout & expiry time. You can make the blacklist efficient by keeping it in memory instead of DB.
• Store Client IP Address in the claims objects JWT. When validating the token you can check with this client's IP address if it is the same source or not. You can refine it based on need like use User-Agent along with Client IP.
• Worst of all reset user credentials or JWT token components to generate a new one which automatically invalidates all existing ones.

Adding a few links for more in-depth detail

Invalidate JWT Token

Destroy JWT Token

Answer 2

I mean it looks more like you should just be using sessions. JWTs are not a simple replacement. They have a specific function and for some reason they have become embedded as some sort of automatic go to for any auth system.

From what you have described (the lifting of a basic auth to a more secure and modern auth system) you should be using sessions. Good ol' Cookie sessions.

I'd go in to why more but to sum up:

A) You can control the session without odd stick on "banlist" tables and extra architecture for the JWTs for users that are banned/logged out for a system that doesn't actually need these if you just used traditional cookie based sessions.

B) They are tried and tested and the browser will keep them safe! Session cookies can be made "secure" and "http-only". There are many odd places people put JWTs including the local/session storage of a browser just waiting for a naughty js injected advert to suck them up. JWTs,just like SessionIDs, should be in an Http-Only, Secure and Same-Site strict Cookie.

So you may as well just use a session ID and get on with life without strange front end state management when the browser is quite happy and doing that securely for you when using a Session Cookie.

C) Traditional sessions are easy to implement. Harder to understand how/why they work with all the SameSite/HttpOnly/CORS/Secure parts going on...but to implement when once understood is 99x easier and require less code when there is the Spring Framework already doing that 99% for you.

I mean sure it isn't hard to write your own JWTAuthTokenAuthFilter and implement a JWTAuthenticationProvider and a JWTCreationService and a `JWTAutoRefreshFilter...and whatever else you dream of...but why bother if you just need a session. Spring does it in like 20 lines of well tested code.

To sum up: I mean of course properly implemented JWTs are secure...it is just maybe they are not always the best fit tool for a job.

Have a read of:

Stop Using JWTs for Sessions

Of course JWTs have a use. They are for letting a 3rd party know "yes, this is someone I know" before the client hits their API end points. Or for say having one of your servers talk to another of yours...or having client's servers talk to yours or even your servers talk to another companies:

JWT Auth - Best Practices