3 ms·
The point of using a stateless token is that you don't have to hit a central server / service to verify each token. If you need to do that in order to check for
by pbz 10y ago
The point of using a stateless token is that you don't have to hit a central server / service to verify each token. If you need to do that in order to check for revoked tokens (for each request) then that defeats the purpose. At that point you may as well just check the original token / key for validity.
The difference in speed between checking for a token in the big pool (all tokens) vs the small pool (revoked tokens) should be a lot smaller than the round trip to token server (i.e. network cost).
Also, you should be able to easily store millions of tokens on a single server (something like Redis). Do you really have a site that has multiple millions of people logged in?
- numbsafari 10y agoSorry if that wasn't clear, but I absolutely agree you should use a distributed revocation list. As each request comes in, you need to check the list. But you do need to check the list, and you do need to distribute it widely. Depending on your situation, managing a revocation list in memory at each edge node might be feasible, reducing the overhead of a network call to a per-cluster store, which is another advantage of using a short revocation list instead of a large session store that can't feasibly be shared like that. (Edit: looking back at my comment, I shouldn't have said a "shared" revocation list, but a distributed one. Whoops!)