Alex Razkevich

Staff Infrastructure Engineer · GCP · reliability · system design

← All posts

OAuth 2.0, Passkeys, and Zero Trust: The Modern Authentication Stack Explained

July 27, 2025

Authentication and Authorization: Why Security Is Never Simple

Let’s be honest — every time you log into an app, there’s a complex dance happening behind the scenes that most people never think about. But if you’re building systems that handle user data (and let’s face it, what system doesn’t these days?), understanding authentication and authorization isn’t optional.

Here’s the thing: these two concepts sound similar but solve completely different problems.

Authentication answers “who are you?” It’s like showing your ID at a bar — you’re proving you’re actually the person you claim to be.

Authorization answers “what can you do?” Even after the bouncer confirms your ID, that doesn’t mean you can walk into the VIP section. Your ticket (or lack thereof) determines what you’re allowed to access.

Why does this matter? Well, mess up authentication and anyone can pretend to be anyone else. Mess up authorization and suddenly your users are seeing each other’s bank statements. Neither scenario ends well for your company’s reputation or your sleep schedule.

How We Prove Identity: A Brief History of Not Getting Hacked

From Simple to Complex (Because Hackers Got Smarter)

Back in the day, authentication was straightforward — you had a username and password, and that was it. This worked fine when computers were room-sized monsters that required physical access. But then the internet happened, and suddenly everyone wanted to break into everyone else’s systems.

Basic Authentication was the internet’s first attempt at “security.” Every single request included your username and password in plain text. Yes, you read that right — plain text. It’s like shouting your credit card number across a crowded restaurant every time you want to pay.

Digest authentication tried to fix this obvious problem by hashing passwords before sending them. Better than nothing, but still not great — hackers could still use rainbow tables to crack those hashes, and the rest of your data was still flying around unprotected.

Token-based authentication was the game changer. Instead of sending credentials with every request, you authenticate once and get a token — think of it as a temporary access pass. Here’s where token rotation becomes crucial: most systems automatically refresh tokens before they expire (typically every 15–60 minutes), giving you a new token while invalidating the old one. Companies like Salesforce take this seriously — their access tokens expire quickly, but they provide refresh tokens that can generate new access tokens without requiring users to log in again.

Multi-factor authentication (MFA) took things further by requiring multiple proofs: something you know (password), something you have (your phone), and sometimes something you are (your fingerprint). Suddenly, stealing just your password wasn’t enough anymore.

The Protocols Everyone Actually Uses

Now we get to the interesting part — the protocols that power most of the apps you use daily. If you’ve ever clicked “Sign in with Google” or logged into Salesforce, you’ve used these technologies.

SAML (Security Assertion Markup Language) is the protocol your IT department loves and developers hate. It’s XML-heavy and complex, but it works well for enterprise SSO. When you log into your corporate network and magically have access to Jira, Confluence, and fifty other tools without typing another password, that’s SAML doing its thing.

OAuth 2.0 is what makes “Sign in with Google” possible. Technically it’s an authorization protocol, but most people use it for authentication too (which is technically wrong, but whatever works, right?). Salesforce, for example, implements OAuth 2.0 with multiple grant types — their web server flow handles the typical redirect dance, while their JWT bearer flow lets trusted applications authenticate directly without user interaction.

OpenID Connect (OIDC) fixes OAuth 2.0’s authentication problem by adding an identity layer on top. When you use Google or Microsoft to sign into other apps, you’re using OIDC. It gives you both an access token (for API calls) and an identity token (to prove who you are). Smart companies like GitHub and Spotify use this for their social login features because why reinvent the wheel when Google has already solved identity management?

In the enterprise world, you’ll still find LDAP directories (think of them as phone books for users), Active Directory (Microsoft’s everything-identity solution), and Kerberos (the protocol that lets you access network resources without typing passwords constantly). Salesforce integrates with all of these through SAML, so your corporate login can seamlessly work with their platform.

These protocols excel because they separate authentication and authorization concerns while providing secure, scalable solutions across platforms. Understanding when to use each protocol is crucial for building robust systems:

Authorization: Just Because You’re In Doesn’t Mean You Can Touch Everything

From Simple Lists to Smart Policies

Once you’ve proven who you are, the next question is: what are you allowed to do? This is where things get interesting (and complicated).

Back in the day, systems used simple Access Control Lists (ACLs) — basically spreadsheets that said “John can read this file, Mary can edit that folder.” This worked fine until you had thousands of users and millions of files. Then it became a nightmare.

Role-Based Access Control (RBAC) was the obvious next step. Instead of managing permissions for each person individually, you create roles like “Editor,” “Viewer,” or “Admin,” then assign people to roles. AWS IAM works this way, as does Kubernetes and pretty much every enterprise app worth using. It’s like having job descriptions that automatically determine what you can access.

Attribute-Based Access Control (ABAC) is the current state-of-the-art. Instead of just checking your role, it looks at everything — who you are, what you’re trying to access, when you’re accessing it, where you’re accessing it from. AWS IAM conditions use this approach (“allow access only from the office IP during business hours”), and Google Cloud IAM does something similar. Open Policy Agent (OPA) is the tool that makes this kind of complex policy management actually manageable.

How Modern Apps Handle “What Can You Do?”

SAML doesn’t just handle authentication — it also carries authorization info. When Salesforce’s SAML response says you’re a “Sales Manager,” that’s not just identity information — it’s telling the receiving application what permissions you should have.

OAuth 2.0 is where things get really interesting for APIs. It’s all about scopes — specific permissions like “read your email” or “post to your timeline.” When you connect Spotify to Discord, OAuth 2.0 handles the “show what you’re listening to” permission without Discord ever seeing your Spotify password.

OAuth 2.0 has several “grant types” (fancy word for “ways to get permission”):

PKCE (Proof Key for Code Exchange) fixes a security hole in OAuth 2.0 for mobile apps and single-page applications. It’s basically OAuth 2.0 with extra proof that you’re the same app that started the authentication flow.

Making This Work in the Real World

Okay, enough theory. Let’s talk about what actually happens when you’re building systems that need to handle authentication and authorization without falling over or getting hacked.

Session Management Strategies

The stateless nature of HTTP requires thoughtful approaches to maintaining user context across requests:

Token-Based Authentication

Token-based authentication has become the preferred approach for modern web applications, offering several advantages over traditional session-based methods:

JSON Web Tokens (JWTs) are self-contained tokens that carry user information and claims. They consist of three parts: a header specifying the algorithm, a payload containing claims, and a signature for verification. JWTs can be:

Server validation approaches include:

Other Ways to Prove You’re You

Session-based authentication is the old-school approach that still powers many web apps. Here’s how it works: after you log in, the server creates a session ID and sends it back in a cookie. Your browser includes this cookie with every request. The server uses headers like Set-Cookie: sessionid=abc123; Max-Age=3600; HttpOnly; Secure to control session lifetime (TTL). Traditional banking sites and many internal enterprise apps still use this because it's simple and well-understood.

API keys are like permanent passwords for machines talking to machines. Think Stripe’s API keys or AWS access keys. Unlike tokens, API keys don’t expire automatically (though they should be rotated regularly). They’re perfect for server-to-server communication where you can’t do the OAuth dance. The key difference from tokens? API keys identify the application, while tokens identify the user.

Certificate-based authentication is the heavy-duty option. Banks and government systems use client certificates to verify both ends of a connection. It’s bulletproof but complex to manage — you need a whole PKI infrastructure just to issue and revoke certificates.

The Password-Free Future (It’s Already Here)

Passwords are dying, and honestly, it’s about time. Here’s what’s replacing them:

FIDO2/WebAuthn sounds scary but it’s actually brilliant. Instead of remembering passwords, you use your fingerprint, face, or a hardware key. Chrome supports this natively, and you’ve probably used it without realizing — when you unlock your phone with your face to pay for something, that’s WebAuthn in action.

Passkeys are Apple, Google, and Microsoft’s attempt to kill passwords once and for all. They’re basically WebAuthn made user-friendly. When you set up a passkey on your iPhone for GitHub, it creates a unique cryptographic key pair. The private key never leaves your device, but you can sync it across your Apple devices through iCloud. Google does the same with Android devices, and Microsoft with Windows Hello.

Cryptographic Foundations

Behind every secure authentication system are robust cryptographic algorithms that protect user credentials:

bcrypt has been a long-standing choice for password hashing, using adaptive hashing with configurable work factors to resist brute-force attacks as computing power increases.

Argon2 is the winner of the Password Hashing Competition and represents the current state-of-the-art in password hashing. It offers three variants (Argon2d, Argon2i, and Argon2id) optimized for different attack scenarios and provides excellent resistance against both time-memory trade-off attacks and side-channel attacks.

PBKDF2 (Password-Based Key Derivation Function 2) remains widely used, particularly in legacy systems and standards compliance scenarios, though it’s generally considered less secure than modern alternatives like Argon2.

Implementation Solutions: Open Source and Managed Services

Rather than building authentication from scratch — a complex and error-prone endeavor — organizations should leverage proven solutions:

Open Source Solutions:

Managed Identity Providers:

These solutions handle the complexity of implementing secure authentication protocols, maintaining compliance standards, and providing scalable infrastructure, allowing development teams to focus on their core business logic.

The Bottom Line

Authentication and authorization are the foundation that many other things around security builds on. Mess them up, and it doesn’t matter how good the rest of your system is.

The practical advice:

Security isn’t something you add later when you have time. It’s like building a house — you can’t retrofit a foundation. The good news? You don’t have to figure this out alone. The protocols and tools discussed here have been battle-tested by companies much larger than yours, dealing with threats much scarier than anything you’re likely to face.

Pick the right tools, implement them correctly, and focus on building the features that actually differentiate your product.