I prefer traditional sessions, but for some systems implement JWTs as well. I'd offer the above but with a couple of slight differences. - Issue tokens contain

I prefer traditional sessions, but for some systems implement JWTs as well. I'd offer the above but with a couple of slight differences. - Issue tokens containing a flag which makes them read-only and give them a short life-time (around a minute). At times of heavy use you're now performing authentication much less frequently in comparison to every request, so less scale is needed. If the token is intercepted it remains a read-only one tied to the context/permissions of the user it was provided to. - When a destructive action is requested (write, delete) if you receive a read-only token reject it. The app will then be forced to re-authenticate to get a write-capable token, which has a lifetime measured in seconds. This covers you for a couple of quick requests and so still reduces load - but the lifetime is very fleeting so revocations, if still needed, are extremely short-lived before the token is expired anyway. If you still want to maintain a revocation list you can stick the tokens in something like Redis with an auto-expiry set to match the token. The short lifespan will keep the revocation list comparatively small and Redis being in memory will make checking it fast. However as the read-only token is only valid for a minute and the write-capable token for a few seconds, there is usually no need to keep a revocation list at all. This all may not seem worth it for the small usage windows you get with a short-lived token, but if your client app/site is refreshing pages or pulling in data via 10 requests in a 2 second window (not uncommon) then you've eliminated 9 authentication requests. At small volumes it doesn't matter, and at large volumes you may reduce the authentication cycles by 90% or more. Again, without needing a revocation list. All that said, use traditional cookies/sessions unless you have complex requirements.