The deceptive simplicity of auth

Decoding ‘auth’: Why authentication v authorization matters more than you think

You saw the title, right? Just using the term “auth” is the first trap we fall into. It feels simple, shorter and techy. But what does it really mean? Authentication? Authorization? Either or both?

That’s the crux of it. We’ve simplified terms to the point where things are muddled. “Auth” becomes a catch-all, and suddenly we see ID tokens (meant for who you are) being used for authorization (what you can do), and access tokens (meant for what you can do) being misused for authentication (who you are).

It’s messy. Even major, established platforms have to build in flexibility for these real-world inconsistencies. And that’s just scratching the surface.

Here’s a quick “auth” refresher

It’s crucial we stay clear on the fundamentals:

1. Authentication (Authn): This is all about identity. It answers the question: Who is this person or system? In the world of OAuth2 and OIDC, this is typically represented by the ID Token. It contains verifiable information about the user’s identity.
2. Authorization (Authz): This is all about permissions. It answers the question: What is this person or system allowed to do? In OAuth2 terms, this is generally handled by the Access Token. It grants specific permissions (scopes) to access certain resources or perform actions.

Services like Auth0, Kinde, WorkOS (and other identity platforms) are fantastic at handling the authentication piece, verifying your users and issuing these tokens. They can also provide information about user roles or permissions to help with authorization. They give you the tokens and the tools.

But — and this is key — enforcing those rules within your product? That’s still on you. It’s your application, your security domain, and rightly so. No external provider should dictate exactly how you secure every endpoint or feature.

When you don’t know what you don’t know, it’s risky

We’ve all heard “there’s no free lunch,” and it definitely applies here. Open source software is one of the modern miracles of our industry. The ability to potentially self-host powerful, world-class authentication solutions using OSS platforms and databases is incredible. We should be immensely proud of that collaborative achievement.

But… (there’s always a but, isn’t there?)

If authentication and authorization were simple problems to solve and maintain, with readily available open-source components, why is the market flooded with dedicated auth providers? Why do companies, large and small, still choose to pay for these services?

The reality is, while the concepts might seem straightforward, it’s not. Implementation, maintenance, security patching, scaling, keeping up with evolving standards (OAuth 2.1, Passkeys, etc.), and handling edge cases are complex, time-consuming, and carry significant risk if done incorrectly.

What is obvious to someone deep in the security field is a minefield for those looking to build it themselves alongside their core product.

Choosing your battles (or choosing your regrets)

There’s rarely a single “perfect” solution when it comes to complex systems like authentication and authorization. Every approach has trade-offs.

• Self-hosting OSS: Amazing flexibility, potential cost savings (in licensing), but requires deep expertise, ongoing maintenance, security vigilance, and resource investment.
• Using a managed service: Offloads complexity, maintenance, and often provides faster access to new features and compliance, but involves vendor lock-in, subscription costs, and trusting a third party.

There are speed bumps down both roads. So it’s less about finding the flawless option and more about understanding the different challenges each path presents. Ask yourself: What problems am I most equipped to handle? Which downsides am I willing to live with?

There’s an old saying: you don’t just run towards the cheese; you also want to run away from the cat. In other words, you’re not just chasing the best solution, you’re also avoiding the most negative outcome.

Is there a perfect system?

Maybe the goal isn’t some feature-packed behemoth, or some bespoke minimalist model. Maybe perfection is closer to Antoine de Saint-Exupéry’s definition:

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”

Perhaps the “perfect” auth system is the one that securely and reliably does exactly what you need it to do, with the least complexity and burden for your specific situation. Finding that balance now, while leaving room to scale, is the real challenge.