3 ms·

I see. Thanks for the clarification. So when you are verifying an incoming JWT, don't you need to check what the allowed counter is for that session? If yes, t

I see. Thanks for the clarification. So when you are verifying an incoming JWT, don't you need to check what the allowed counter is for that session? If yes, then doesn't that require a database / cache lookup for each verification? And if it does, then how are you able to get super fast session verification?

endiangroup 6y ago
Yes absolutely, as I stated in the comment before. The super fast verification is once you've done the DB lookup and do the actual comparing (as it's just int64 comparisons). CAA is intended as a set of primitives to be built on top of. As I understand ST is in effect making the client act as the cache by giving them a refresh token (RT), you delay having to do a central DB lookup until the AT expires and RT is used... You could do the same with CAA, check the DB every X interval (30s) instead of every request, the security implications would be the same (some period of time that no matter who is using the token it will work) as I understand? From what I've read Theft Protection is a matter of detecting reuse of RT (as I've understood), again with CAA and using the above, you could track each periodic "check" against the master with another counter and embed into the token, if you see a tracking number < or > what you've seen then a Theft has occurred. Would that be the same as ST?
- rishabhpoddar 6y ago
  Yea! Absolutely. Both our solutions follow the same fundamental idea of changing tokens to detect theft. That being said, there are edge cases that need to be considered when detecting token theft such that there are no false positives: https://youtu.be/6Vzit514kZY?t=747 https://youtu.be/6Vzit514kZY?t=747. The video about describes 2 edge cases specific to our flow, but I maybe they also apply to your solution?

3 ms·

I see. Thanks for the clarification. So when you are verifying an incoming JWT, don't you need to check what the allowed counter is for that session? If yes, t

by rishabhpoddar 6y ago

endiangroup 6y ago
Yes absolutely, as I stated in the comment before. The super fast verification is once you've done the DB lookup and do the actual comparing (as it's just int64 comparisons). CAA is intended as a set of primitives to be built on top of. As I understand ST is in effect making the client act as the cache by giving them a refresh token (RT), you delay having to do a central DB lookup until the AT expires and RT is used... You could do the same with CAA, check the DB every X interval (30s) instead of every request, the security implications would be the same (some period of time that no matter who is using the token it will work) as I understand? From what I've read Theft Protection is a matter of detecting reuse of RT (as I've understood), again with CAA and using the above, you could track each periodic "check" against the master with another counter and embed into the token, if you see a tracking number < or > what you've seen then a Theft has occurred. Would that be the same as ST?
- rishabhpoddar 6y ago
  Yea! Absolutely. Both our solutions follow the same fundamental idea of changing tokens to detect theft. That being said, there are edge cases that need to be considered when detecting token theft such that there are no false positives: https://youtu.be/6Vzit514kZY?t=747 https://youtu.be/6Vzit514kZY?t=747. The video about describes 2 edge cases specific to our flow, but I maybe they also apply to your solution?