New lesson: Session Management in Practice

nodeJS/authentication/stateful_vs_stateless_authentication.md

@@ -28,9 +28,9 @@
 
 JWTs are much harder to invalidate. Say you generate one with a 2-day expiry and the client then logs out, deleting it from whatever storage medium was used. The client no longer has the token but since it's just text, anyone else who has that text could continue to use it and it will still be valid until expiry. This could have been obtained via any number of malicious attack methods, including [cross-site scripting (XSS)](https://en.wikipedia.org/wiki/Cross-site_scripting) and [cross-site request forgery (CSRF)](https://en.wikipedia.org/wiki/Cross-site_request_forgery), especially if the token is stored somewhere like in local storage. At the most basic level, a pesky sibling/roommate could have gone on your computer, opened devtools, then copied down the JWT value to use on their machine.
 
-The same applies to now-demigod Odin. His father Borr took away his "god" token but luckily, his brother Vili had a copy so now Odin can go around pretending to be a full-blown god again. Hence the lack of invalidation becomes a particular issue for stale data in tokens that may contain things like authorization data.
+The same applies to now-demigod Odin. His father Borr took away his "My name is Odin and I'm a god" token but luckily his son, Loki, had a copy. So now Odin can go around pretending to be a full-blown god again. Even worse, Loki could go around pretending to be his father!
 
-Since the server does not store the tokens, it cannot directly invalidate them without changing the secret used to sign them, but then that will invalidate *every* users' tokens. Keeping a server-side list of revoked tokens would just make things stateful (almost like a more complex version of sessions), since every authenticated request must query that revocation list before verifying any tokens. Setting a super-short expiry time like a few minutes would definitely reduce how long a malicious actor could use a stolen JWT to wreak havoc, but then that'd ruin the user experience for everyone else if they could only stay logged in for a few minutes at a time (though of course this is sometimes an intended security feature, like with many banking websites).
+Since the server does not store the tokens, it cannot directly invalidate them without changing the secret used to sign them, but then that will invalidate *every* users' tokens. Keeping a server-side list of revoked tokens would just make things stateful (like a more complex version of sessions), since every authenticated request must query that revocation list before verifying any tokens. Setting a super-short expiry time like a few minutes would definitely reduce how long a malicious actor could use a stolen JWT to wreak havoc, but then that'd ruin the user experience for everyone else if they could only stay logged in for a few minutes at a time (though this is of course sometimes an desirable security feature, like with many banking websites).
 
 #### A hybrid approach
 
@@ -48,7 +48,7 @@
 
 <div class="lesson-content__panel" markdown="1">
 
 1. Read ["Stop using JWT for sessions"](http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/) for a breakdown of why the proposed benefits of JWTs (for essentially the same thing as sessions) may not be worth the complexities and potential vulnerabilities.
 1. Read another take on [avoiding JWTs to implement browser sessions](https://ianlondon.github.io/posts/dont-use-jwts-for-sessions/).
 
 </div>