Refresh tokens should not be stored in database as it makes the whole architecture state full.
Assadullah-Khan opened this issue · comments
Hey there, thanks for raising the issue. I disagree.
-
Based on the experience / auditory requirements, you may need a durable store for refresh tokens. Without storing refresh tokens, a short lived JWT cannot be refreshed against the server and the client would have to forcibly login again. This may/may not be the experience you might be looking for.
-
Choosing a relational database as a store vs a store optimized for high read / low writes is debatable. You can optionally choose a store that supports TTL but some kind of a "data store" may be required.
-
You could have policies on the refresh token and might want to do some analytics. Not storing refresh tokens doesn't enable you to do either.
-
Stateless operations are okay for short lived JWT but not for long lived refresh tokens. If the "deterministic" logic of generating a refresh token from a JWT leaks out, the client may stay logged in for an indefinite amount of time unless active session monitoring / observability is in place.
Disclaimer
This project is meant to serve as a PoC and by no means ready to be used in production :)
The architecture of a production ready system can make use of multiple optimisations including not storing refresh tokens in a store. Feel free to share your thoughts with the community.
It totally depends on case to case basis. If you prefer to have some analytics or observe ability or any sort of policies. It might be OK for you.
But for general or abstract use cases, i prefer to not store the refresh tokens in data stores.
Any how if you disagree, you may close this issue.