• Misuse of a Specific Standard: JSON Web Tokens (JWTs) were fundamentally architected as short-lived (~5 minutes or less) Single Sign-On (SSO) or federation data transports, yet they are widely and improperly implemented by developers for long-lived, web-browser user sessions.
• The Stateless Authentication Illusion: True stateless user sessions are an architectural fallacy if security is a priority. Handling instant logouts, immediate user bans, or privilege changes requires maintaining a stateful data store; if a database or distributed cache must be queried anyway, an opaque session ID cookie is simpler and more secure.
• Inherent Specification Vulnerabilities: The JOSE/JWT family specification is heavily criticized by security experts for its excessive complexity and historically relaxed parameters—such as permitting an alg: "none" signature type or exposing systems to public/private key confusion attacks.
• Performance Fallacies: While developers often adopt JWTs to eliminate database lookup overhead on every API request, standard session tokens managed inside a fast key-value store (e.g., Redis or Valkey) introduce negligible latency and avoid the bloated payload size of heavily cryptographic JWTs.
• The Bootcamp Propagation Loop: The adoption of JWTs for basic web app authentication is largely driven by a propagation loop of unvetted blog posts, tutorials, and coding bootcamps that prioritize trends and perceived simplicity over battle-tested security standards.
• Alternative Approaches: For scenarios that legitimately demand short-lived, cryptographically signed tokens, modern secure-by-default specifications like PASETO (Protocol-Agnostic Security Tokens) should be chosen over the flaw-prone JWT standard.

Hacker News Discussion

• Historical vs. Modern Library Security: Several commenters argue that JWTs are safer today because modern, cross-language libraries have finally hardened their defaults (e.g., stripping out alg: "none" support). However, security purists counter that a spec requiring ongoing, scattershot library audits to prevent basic misuse is inherently broken by design.
• Revocation List Overhead: Proponents of JWTs claim that managing an invalidation/revocation list for unexpired JWTs requires orders of magnitude less memory and database storage than maintaining a global registry of every single active session in a large-scale system.
• The DB Lookup Reality: A counterargument highlights that even with a verified JWT, applications almost always perform a database lookup on the accompanying user or identity object anyway to check if an account is still active or authorized, completely neutralizing the "stateless" performance benefit.
• Invalidation Workarounds and State Creation: Some users suggest bypassing individual token revocation lists by adding a tokens_not_valid_before timestamp to a user profile, which updates to now() on logout. Critics point out that this still creates system state and inadvertently forces a nuclear logout across all of a user's active devices instead of just one.
• Legitimate Distributed and Agentic Use Cases: Commenters emphasize that JWTs remain highly valuable for cross-region edge microservices (e.g., replicating compact, short-lived revocation lists between Japan and Europe) and delegating scoped execution permissions to modern third-party subagents.

Can be used between microservices architecture to share user info and facilitate auth among services.

[transfer fo trust/credentials]

Try to turn on token-based authentication on DRF (http://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication) and then follow the usual install of DRF-JWT, then added djoser and it works right of the box with no modifications to the code.

A useful intro to the angular-jwt service that we use in H for auth.