Exercise 3: Revoking a Session vs. Revoking a JWT — Possible Solution
====================================================================

WHY ENDING A LARAVEL OR DJANGO SESSION IS SIMPLE
------------------------------
Per this chapter, both Laravel's and Django's default authentication models are session-based - the server holds a session record, and logging out is a single server-side call (session()->invalidate() in Laravel, Django's own logout()) that immediately removes or invalidates that record. Once invalidated, the session is unusable everywhere, instantly, because the server itself is the single source of truth for whether it's still valid.

WHY REVOKING A NEXTAUTH JWT IS HARDER
------------------------------
Per this chapter, Next.js Rebuild 9's NextAuth setup issues a signed JWT stored in a cookie instead of a server-side session record. A JWT is self-contained and verifiable purely by its signature, with no server-side lookup required to accept it - which means there is no single server-side record to delete in order to revoke it early. The token simply remains valid, from the server's point of view, until its own built-in expiry time arrives, regardless of any logout action taken in the meantime.

WHAT A JWT-BASED APPROACH WOULD NEED TO ADD
------------------------------
Per this chapter, closing this gap requires a deliberate token-blacklist strategy - some server-side record of tokens that should be rejected even though their signature and expiry are still technically valid, checked on every request in addition to the normal signature/expiry validation. This reintroduces a server-side state check the token-based model was originally trying to avoid, just scoped narrowly to revoked tokens rather than to every active session.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that session-based logout works by deleting a single server-side record, correctly explains that a JWT has no equivalent server-side record to delete and instead relies on its own expiry, and correctly identifies a token-blacklist as the mechanism a JWT-based approach would need to add to support early revocation.