JWT helped me to achieve authentication and authorization without needing to make a trip to database on every API call. I use to store user role code in the token.
I kept the token expiry to an hour or two depending upon the usecase.
Added logic to client to refresh the token right before expiry of existing token. Otherwise, on token expiry, server returns 401 and client can attempt to refresh token or send user to login page.
If there is a need of instant revocation, then I can maintain a list of revoked tokens for the duration of token life (1-2 hours) in cache layer. After 1-2 hours token will be expired anyway.
In memory caches have scalable concerns and require sticky load balancer. You'd need to decentralize the cache (eg create a db for the session information) to allow horizontal scaling of services so this approach is generally considered old-school.
JWT has its own slew of problems, most of them are temporal (eg invalidation of all sessions), usability (eg short expiry), or additional security vectors (many poor JWT implementations, accidentally authenticating invalid tokens w/o signing, careless storage of readable values)
Hmm never had an issue with in memory caching and scalability (except in the old days of memcache). One can send a unique and hard to guess pair of identifiers and drop the lb stickiness. anyway depends on the use case, but i feel like given the symptoms you describe there are a few other ways of doing it without jwt.
For sure - they're just considerations/complexities if you need to quadruple your service infrastructure for black friday or what not.
I don't feel JWT is often appropriate - I wrote one of the early scala implementations so have seen the lifecycle of a security library.
Typically, before stuff like JWT was popular, you would store a session in the db and the session id in a cookie. Then you would hit the db each request to check if the session was valid.
I’ve found that writing starless services makes my life significantly easier. Also I may need to query several apis to render a single page. Each one needs to know who is calling it.
I kept the token expiry to an hour or two depending upon the usecase.
Added logic to client to refresh the token right before expiry of existing token. Otherwise, on token expiry, server returns 401 and client can attempt to refresh token or send user to login page.
If there is a need of instant revocation, then I can maintain a list of revoked tokens for the duration of token life (1-2 hours) in cache layer. After 1-2 hours token will be expired anyway.