Hacker News Reader

Comment by endiangroup | Hacker News Reader

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.

View on HN

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?

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?

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.

The video about describes 2 edge cases specific to our flow, but I maybe they also apply to your solution?

Reply on news.ycombinator.com