3 ms·

Your first point is mostly dead on. I see a number of people stating that you cannot revoke a token, and it's simply not true. The approach I use is to replace

Your first point is mostly dead on. I see a number of people stating that you cannot revoke a token, and it's simply not true. The approach I use is to replace the shared session store (which is large, grows linearly with your user base, and hard to sync across clusters if you need that) with a shared revocation list. The revocation list is small, easy to check, only contains IDs and a TTL, much less cumbersome to replicate... And is functionally equivalent. If you have already gone the route of using a token for your session, it's really easy to implement and scales much better than a massive in memory store.

merb 10y ago
actually I often see stating that you should rely on a 3rd party authentication library since its mostly well known and well tested. While I would agree here I know that mostly the library will be your weak point since you have no idea how its implemented or whenever a new version comes around if it maybe has a security issue or if you keep your version if your vulnerable to something. Actually most people should take their authentication mechanism as something really really important and not just rely on something. It's really important that your authentication/authorization stuff works and is hardened, not just for you, also for your users. I know that auth could be really hard, especially when the language of your choice contains some bugs, but its a nogo to just use something when it is that important. I don't mean that you can't use a library, but if you do please double check the code twice on each version.
- niteshade 10y ago
  I actually think your advice is more harmful than helpful - web developers are not renowned for writing secure software. This is a very good case of finding a good, well-tested and vetted library that does this. Not sure what options exist, but I would be highly surprised if there weren't any already.
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 ago
  Sorry 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!)

merb 10y ago

actually I often see stating that you should rely on a 3rd party authentication library since its mostly well known and well tested. While I would agree here I know that mostly the library will be your weak point since you have no idea how its implemented or whenever a new version comes around if it maybe has a security issue or if you keep your version if your vulnerable to something. Actually most people should take their authentication mechanism as something really really important and not just rely on something. It's really important that your authentication/authorization stuff works and is hardened, not just for you, also for your users. I know that auth could be really hard, especially when the language of your choice contains some bugs, but its a nogo to just use something when it is that important. I don't mean that you can't use a library, but if you do please double check the code twice on each version.

niteshade 10y ago
I actually think your advice is more harmful than helpful - web developers are not renowned for writing secure software. This is a very good case of finding a good, well-tested and vetted library that does this. Not sure what options exist, but I would be highly surprised if there weren't any already.

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 ago
Sorry 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!)