At some point in your developer journey, you were told to use JWTs for authentication. For some, it was from a YouTube tutorial. For others, a blog post or perhaps a senior member of your team. Either way, you pasted the code, got a token and logged in. All was well.
But then, something broke.
The problem is with the way we talk about authentication. We often reduce it to implementation details like "use JWT" or "store the token here" without asking the important questions. Why this token format? Why this flow? Why this storage method?
The truth is JWT is just a format. A way to package data. It is not a full authentication system. It does not handle how tokens are issued. It does not protect against interception. And it definitely does not teach you how to secure your application.
Limitations of JWT as a One-Size-Fits-All Solution
JWTs are great for certain use cases. They are self-contained, compact and easy to parse. They also come with risks that many developers might overlook or not fully understand.
JWT (JSON Web Token) is a way to represent claims between two parties. It's commonly used to authenticate users by embedding their info (like ID or role) in a signed token that can be passed between the frontend and backend.
A few problems show up in the real world:
- Long-lived tokens stored in localStorage become a liability. If someone gets access to the browser storage, they own the token.
- Lack of token revocation means that once a JWT is issued, it is valid until it expires. If it gets stolen, the system has no built-in way to kill it.
- Too much data in the token makes it vulnerable to leaks. Some developers include sensitive user information in the payload, which gets base64 encoded — not encrypted.
So yes, JWTs are useful. But they are not secure by default. And they are definitely not enough on their own.
What OAuth 2.1 Actually Solves
OAuth 2.1 removes outdated flows, enforces better defaults and makes things safer for public clients like single-page apps and mobile apps.
OAuth (Open Authorization) is a protocol that allows third-party applications to access user data without exposing their password.
Some key changes worth knowing:
- The implicit flow is deprecated. This is huge. In earlier versions, SPAs would request tokens directly from the authorization server without a code exchange step. That approach exposed tokens in the browser and skipped key validation steps.
- OAuth 2.1 enforces the use of authorization code flow with PKCE, even for public clients. This adds a layer of protection during the token exchange.
- Refresh tokens for SPAs are now handled with more nuance, using rotating refresh tokens and secure storage patterns.
The shift is subtle but meaningful. It basically means: we know how developers actually build apps today. Let's secure it properly.
What Exactly is PKCE
PKCE is not hard to understand. It is essentially a way to prove that the app requesting the token is the same app that started the process.
PKCE (Proof Key for Code Exchange) is a security extension to OAuth. It protects the authorization code flow, especially in public clients that can't securely store secrets.
Here's how it works:
- The app generates a random string called a code verifier.
- It hashes this value and sends the code challenge to the authorization server.
- Later, when the app tries to exchange the authorization code for a token, it must provide the original code verifier.
- The server checks if the hashed verifier matches the challenge sent earlier.
- This prevents attackers from intercepting the authorization code and using it. Without the original code verifier, the exchange fails.
PKCE protects against a real and common threat. And it works without needing a client secret.
Real-World Authentication
Authentication is not just about passing the test case. It is about withstanding the real-world messiness of browsers, devices, networks and users.
Some things to keep in mind:
- Use short-lived access tokens and long-lived refresh tokens. Always rotate refresh tokens on use.
-
Store tokens securely. In web apps, avoid
localStorage. Use HTTP-only cookies withSameSiteandSecureflags when possible. - Adopt token revocation strategies. Blacklists, rotation and introspection endpoints can help.
- Rely on trusted auth providers unless you have a good reason to build your own. Auth0, Clerk, Okta and others have done the hard work.
- Log and monitor. Treat authentication failures and token activity as security events. Alert when something unusual happens.
The goal is not just to authenticate users. The goal is to protect the system, the data and the people using it.
Why Does Any Of This Matter?
The rise of AI tools and frameworks has made authentication feel like a solved problem. Paste this, configure that and it works.
Until it doesn't.
Good authentication is not just about getting users in. It's about building trust, preventing abuse and laying the foundation for a system that can grow without security breaches.
You don't need to become an OAuth expert. But you do need to care about the decisions being made on your behalf.
JWTs, OAuth and PKCE. They all have the same goal with different approaches. But when used together — and correctly — they form the backbone of modern authentication systems that actually scale.
The key is to approach auth like you approach any other part of software engineering. With clarity. With care. With context.
If you're building an app that handles user data, it is your responsibility. Proper authentication should never be an afterthought. It is a core part of the user experience and system security.