New lesson: Stateful vs Stateless Authentication

[MaoShizhong]

Because

As part of the Node revamp's 2nd milestone

This PR

• Adds a new lesson comparing stateful and stateless authentication in the context of TOP

Issue

Closes #29735

Pull Request Requirements

• I have thoroughly read and understand The Odin Project curriculum contributing guide
• The title of this PR follows the location of change: brief description of change format, e.g. Intro to HTML and CSS lesson: Fix link text
• The Because section summarizes the reason for this PR
• The This PR section has a bullet point list describing the changes in this PR
• If this PR addresses an open issue, it is linked in the Issue section
• If any lesson files are included in this PR, they have been previewed with the Markdown preview tool to ensure it is formatted correctly
• If any lesson files are included in this PR, they follow the Layout Style Guide

[01zulfi]

lgtm 🚀

[Asartea]

Suggested change

In previous lessons we covered both stateful authentication (demonstrated using sessions) and stateless authentication (using JWTs). You will often see both approaches out in the wild, which may not necessarily be implemented with sessions or JWTs specifically, but why the options? What are the pros and cons of each? How should I authenticate my applications? We will explore and compare our options in this lesson specifically in the context of projects for the rest of this course, where we implement authentication for the purpose of login persistence (session management).

In previous lessons, we covered both stateful authentication (demonstrated using sessions) and stateless authentication (using JWTs). You will often see both approaches out in the wild, although not necessarily implemented using sessions or JWTs, so why choose one over the other? What are the pros and cons of each? How should you authenticate your applications? We will explore and compare our options in this lesson, specifically in the context of the remaining projects in this course, where authentication is used for login persistence (session management).

Slightly tighten up the sentence structure and avoid switching between pronouns (you vs I).

[Asartea]

Suggested change

	Stateful authentication involves authentication data being stored server-side, such as in a session, while stateless authentication stores the data client-side, such as in a JWT. Why might one pick a stateless solution over a stateful one or vice versa, especially when you'll find many JWT tutorials online and various contrasting opinions across online forums?
	Stateful authentication involves authentication data being stored server-side, such as in a session, while stateless authentication stores the data client-side, such as in a JWT. Why might one pick a stateless solution over a stateful one or vice versa?

Not sure this last part is necessary?

[Asartea]

nit:

Suggested change

Stateless solutions reduce the amount of database calls needed per authenticated request, as a call is not needed to check the database for a matching session - the data is already there in the request and need only be verified. But is this actually a problem? At what point does this additional database call become a performance bottleneck in a stateful solution? While much larger products built with more complex architectures may well need to consider this, in all honesty, this is almost certainly not going to be an issue for many small projects, certainly not curriculum projects (and if it genuinely does, congratulations on the successful site!).

Stateless solutions reduce the amount of database calls needed per authenticated request, as a call is not needed to check the database for a matching session - the data is already there in the request and needs only to be verified. But is this a problem? At what point does this additional database call become a performance bottleneck in a stateful solution? While much larger products built with more complex architectures may well need to consider this, it is almost certainly not going to be an issue for many small projects, certainly not curriculum projects (and if it genuinely does become an issue, congratulations on the successful site!).

[Asartea]

Fleshes out the last sentence a bit

Suggested change

	But is there actually a negative to using something like JWTs for stateless authentication? Potentially: **authorization** and **invalidation**.
	But is there actually a negative to using something like JWTs for stateless authentication? Yes, particularly when it comes to **authorization** and **invalidation**.

[Asartea]

nits

Suggested change

Imagine if Odin was demoted from "god" to "demigod". meaning he's no longer allowed to access the god-only section of Valhalla. If the JWT stored role information, that information is now **stale** yet it still exists. As long as Odin still has that JWT, he could fool anyone into thinking he was still a full-blown god and not a demigod! Ideally the database holds the source of truth for these things, and we query it only once we have verified who is making the request. While this is still something that can occur when using sessions (i.e. storing permissions in the sessions themselves), at the very least session data is not stored client-side for anyone to see or take for themselves. This also leads us straight into the next issue to address.

Imagine if Odin was demoted from "god" to "demigod", meaning he's no longer allowed to access the god-only section of Valhalla. If the JWT stored role information, that information is now **stale**, yet it still exists. As long as Odin still has that JWT, he could fool anyone into thinking he was still a full-blown god and not a demigod! Ideally, the database holds the source of truth for these things, and we query it only once we have verified who is making the request. While this can still occur when using sessions (i.e. storing permissions in the sessions themselves), at the very least session data is not stored client-side for anyone to see or take for themselves. This also leads us straight into the next issue to address.

[Asartea]

I feel like this scans slightly better:

Suggested change

	How do you invalidate a session, such as when a user logs out? You just delete the session from the database. Now no matter who has the old session ID, there won't be a matching session and so it's now invalid. Now how do you do it with something like a JWT? As per the JWT lesson, you'd delete the JWT from the client. But does that actually mean the JWT is no longer valid?
	How do you invalidate a session, such as when a user logs out? You just delete the session from the database. Now, no matter who has the old session ID, there won't be a matching session, and so it's now invalid. Now, how do you invalidate something like a JWT? As per the JWT lesson, you'd delete the JWT from the client. But does that actually mean the JWT is no longer valid?

[Asartea]

nits:

Suggested change

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).

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 user's 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 can be a desirable security feature, like with many banking websites).