3 ms·

Yes but then you add revocation and you are back at a centrally stored database to check against.

xnorswap 5y ago
That's correct. There are scenarios where it still makes sense. It's plausible that it would more efficient for some high traffic services to push (the somewhat rare) revocation notices out to endpoints as still being more efficient. For example imagine a whatsapp clone. People send thousands (probably tens of thousands) more messages than they issue password/auth resets. Having the incoming message endpoint maintain a cache of recently expired tokens would let you set a reasonably long (e.g. 24 hr) token expiry. You could have the app re-auth in the background on start-up and/or when it detects the expiration window is closing, while incoming messages avoid hitting the central DB for auth. Maintaining a cache of expired tokens pushed to endpoints would be vast orders of magnitude smaller than maintaining a cache of all session keys. I don't know for sure though, perhaps central session caches are just more practical and secure anyway for these kind of end-user endpoints. In some ways this is similar to the Certificate Revocation List handles certs. There are certificate revocation notices that are used instead of needing to check centrally the validity of all certificates. That said, the CRL has essentially been deprecated in preference of a lookup model.
- heavenlyblue 5y ago
  Actually I never thought about this problem this way, but it seems like in an abstract way the difference between the password and the revocation lists is that of the size of the set: What is larger, the set of all passwords, or the set of all revoked users? In most cases the set of all revoked users would be multiple orders of magnitude smaller than the set of of all passwords. Thanks for writing this message, it made it click for me for some reason.
- ptsneves 5y ago
  Then in this scenario it means you will trust the clients to honor the list of bad tokens is it not? Is this not the whole reason bearer authentication is insecure? Either you need to check in the server against a database or you need to trust your clients that they checked against the database..

That's correct. There are scenarios where it still makes sense. It's plausible that it would more efficient for some high traffic services to push (the somewhat rare) revocation notices out to endpoints as still being more efficient. For example imagine a whatsapp clone. People send thousands (probably tens of thousands) more messages than they issue password/auth resets. Having the incoming message endpoint maintain a cache of recently expired tokens would let you set a reasonably long (e.g. 24 hr) token expiry. You could have the app re-auth in the background on start-up and/or when it detects the expiration window is closing, while incoming messages avoid hitting the central DB for auth. Maintaining a cache of expired tokens pushed to endpoints would be vast orders of magnitude smaller than maintaining a cache of all session keys. I don't know for sure though, perhaps central session caches are just more practical and secure anyway for these kind of end-user endpoints. In some ways this is similar to the Certificate Revocation List handles certs. There are certificate revocation notices that are used instead of needing to check centrally the validity of all certificates. That said, the CRL has essentially been deprecated in preference of a lookup model.

heavenlyblue 5y ago
Actually I never thought about this problem this way, but it seems like in an abstract way the difference between the password and the revocation lists is that of the size of the set: What is larger, the set of all passwords, or the set of all revoked users? In most cases the set of all revoked users would be multiple orders of magnitude smaller than the set of of all passwords. Thanks for writing this message, it made it click for me for some reason.
ptsneves 5y ago
Then in this scenario it means you will trust the clients to honor the list of bad tokens is it not? Is this not the whole reason bearer authentication is insecure? Either you need to check in the server against a database or you need to trust your clients that they checked against the database..