3 ms·

Sounds interesting! I'll have a look at your library. Our solution takes relevant aspects of the OAuth specs. Specifically the idea of using rotating refresh to

Sounds interesting! I'll have a look at your library. Our solution takes relevant aspects of the OAuth specs. Specifically the idea of using rotating refresh tokens to detect session theft. That being said, we have not had any formal verification. We plan on doing an outside code review / audit from a reputable 3rd party in the coming weeks. Two question for you: - In your solution, I assume there is one JWT per logged in user. If I want to revoke one user's session specifically (without affecting other users who have a similar count), how would I do that? - When would I want to revoke all sessions before some count X? Apologies if I have misunderstood how your lib works.

endiangroup 6y ago
Good luck with the audit, the solution sounds interesting on the surface! Ah I think you've slightly misunderstood, there is a 'counter' per entity, each user has their own separate counter so when you are revoking it is only relevant to sessions related to that users account. This would fall under your database lookup version of JWT management, it's centralised but in the smallest way possible. That might clear up your second question, you'd want to revoke all sessions like I'd want to 'Log out all other active sessions', logging in to my Spotify on my friends computer last week, and my sisters the week before, I want to log them ALL out.
- rishabhpoddar 6y ago
  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?

endiangroup 6y ago

Good luck with the audit, the solution sounds interesting on the surface! Ah I think you've slightly misunderstood, there is a 'counter' per entity, each user has their own separate counter so when you are revoking it is only relevant to sessions related to that users account. This would fall under your database lookup version of JWT management, it's centralised but in the smallest way possible. That might clear up your second question, you'd want to revoke all sessions like I'd want to 'Log out all other active sessions', logging in to my Spotify on my friends computer last week, and my sisters the week before, I want to log them ALL out.

rishabhpoddar 6y ago
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?