4 ms·
You only have to do that if you must validate a token, without having access to session data. I doubt most systems are like that, you can just use what you cal
by ars 1y ago
You only have to do that if you must validate a token, without having access to session data.
I doubt most systems are like that, you can just use what you call "your actual token" and check if the session is still valid. Adding a second token is rarely needed unless you have disconnected systems that can't see session data.
- fastball 1y agoNot having to start all my API handlers with a call to the DB to check token validity significantly improves speed for endpoints that don't need the SQL db for anything else, and reduces the load on my SQL db at the same time.
- ars 1y agoDoes it actually improve speed though? The DB check is simply "does this key exist", it can be done in a memory database, it doesn't have to be the same DB as the rest of your data. Validating a token requires running encryption level algorithms to check the signing signature, and those are not fast.
- fastball 1y agoIt definitely improves speed. Crypto algos are slow, but they are not slower than a TCP roundtrip. Even a memory database is not generally running on the same machine, so there is still a round-trip cost vs a JWT. Also, although it doesn't need to be the same DB, it adds more complexity to store such a key in a different DB than your actual user data (where the original auth logic is coming from).
- RadiozRadioz 1y agoThen don't hit the SQL DB directly, cache the tokens in memory. Be it Redis or just in your app. Invalidate the cache on token expiry (Redis has TTL built in). UserID -> token is a tiny amount of data.
- fastball 1y agoAnd now I need to invalidate the cache if the key is invalidated. Also this cache cannot be updated/invalidated atomically, like I can if I'm just storing a refresh key in the SQL db. Caching in Redis is more complex and more prone to error than access/refresh token systems.
- RadiozRadioz 1y agoDude, you can't have it both ways, pick one. You didn't want load on the DB, so you need to cache things somehow. Dealing with cache invalidation is a natural consequence. Ok then, keep the DB, provision a distributed array of read replicas, make them use synchronous replication to maintain your atomicity, force them all of them to keep the session table in memory. Now your cache is managed by the DB and meets all your requirements.
- fastball 1y agoI can have it both ways, that is the entire point of the refresh/access token system. The access tokens are used for 99% of requests (every request except "refresh" requests) and I am not persisting them anywhere – there is no cache/db read. It is a quick, CPU-bound check to decrypt the token, no i/o required. Your newly proposed solution sounds much more complicated than the above.
- RadiozRadioz 1y agoAh right, my apologies, I seem to have misunderstood here. For some reason I thought your initial comment was narrowly discussing the issue of DB load in a system that doesn't use refresh tokens. Upon re-reading the thread context I have no idea why I thought that. Yes of course, refresh tokens are the best solution