3 ms·

>You are essentially powerless, and cannot 'kill' a session without building complex (and stateful!) infrastructure to explicitly detect and reject them, defeat

by homakov 10y ago

>You are essentially powerless, and cannot 'kill' a session without building complex (and stateful!) infrastructure to explicitly detect and reject them, defeating the entire point of using stateless JWT tokens to begin with. just autoincrement nonce=123 and revoke it any time. Nothing complex about it. >it can also mean somebody has a token with a role of admin, even though you've just revoked their admin role. nobody stores user mode in session, that's what DB for. >but without the battle-tested implementations. "I don't know what's wrong but I'm kinda afraid to try". Best argument so far is that it's indeed longer. Bottom line: Use JWT for sessions, they are awesome! In Rails we're using similar mechanism for years already.

kelson 10y ago
> just autoincrement nonce=123 and revoke it any time. Does that revoke all tokens (shared "nonce") or update the token on next authentication? Would this "nonce" be stored in the database? > nobody stores user mode in session That's optimistic: https://github.com/akagadovskiy/ng-admin-jwt-auth/blob/master/js/authService.js https://github.com/akagadovskiy/ng-admin-jwt-auth/blob/maste... > > but without the battle-tested implementations. > "I don't know what's wrong but I'm kinda afraid to try". Battle-tested implementations have dealt with (at least some of) these threats previously. New approaches often miss the lessons of past efforts, leaving themselves vulnerable to old attacks.
- homakov 10y ago
  > Would this "nonce" in the database? Only in revoked list=1,2,5,7 etc. Unlike storing all sessions, you only store revoked integers which takes way less space and achieves same revocation you wanted. > That's optimistic Nobody should store > leaving themselves vulnerable to old attacks Every new line of code is probably a vulnerability. That's life. BTW JWT indeed had some super stupid bug with alg=NONE before, and I would simply throw away "header" from JWT

by homakov 10y ago

kelson 10y ago

> just autoincrement nonce=123 and revoke it any time. Does that revoke all tokens (shared "nonce") or update the token on next authentication? Would this "nonce" be stored in the database? > nobody stores user mode in session That's optimistic: https://github.com/akagadovskiy/ng-admin-jwt-auth/blob/master/js/authService.js https://github.com/akagadovskiy/ng-admin-jwt-auth/blob/maste... > > but without the battle-tested implementations. > "I don't know what's wrong but I'm kinda afraid to try". Battle-tested implementations have dealt with (at least some of) these threats previously. New approaches often miss the lessons of past efforts, leaving themselves vulnerable to old attacks.

homakov 10y ago
> Would this "nonce" in the database? Only in revoked list=1,2,5,7 etc. Unlike storing all sessions, you only store revoked integers which takes way less space and achieves same revocation you wanted. > That's optimistic Nobody should store > leaving themselves vulnerable to old attacks Every new line of code is probably a vulnerability. That's life. BTW JWT indeed had some super stupid bug with alg=NONE before, and I would simply throw away "header" from JWT