The Uptime Engineer
👋 Hi, I am Yoshik Karnawat
You'll learn why SSO isn't OAuth (even though everyone uses them interchangeably), how a single redirect carries your identity across dozens of apps without touching passwords, and why the token signature matters more than the token itself.
By the end, you'll understand the exact 6-step flow that happens when you click "Sign in with Google," know which protocol to choose between SAML and OIDC based on your users (not hype), and debug multi-tenant auth failures by tracing the iss claim instead of restarting services.
🔧 This Week's Command
curl -s "https://accounts.google.com/.well-known/openid-configuration" | jq '.jwks_uri'Discover an IdP's public key endpoint (JWKS) from their OIDC discovery metadata. Essential for debugging SSO token validation failures or verifying which signing keys your app should trust.
🔥Tool Spotlight
Keycloak. Open-source Identity Provider supporting SAML, OAuth2, and OIDC. Self-hosted alternative to Auth0/Okta. Handles 100k+ users, custom auth flows, and federation. Perfect for multi-tenant SaaS.
💼 Hot Jobs
Senior DevOps Engineer (AWS) @ Proxify AB - Remote
Apply →
Lead DevOps Engineer – Azure, Terraform @ NorthBay Solutions- Remote
₹2.8M - ₹3.1M / year
Apply →
You click "Sign in with Google."
Three seconds later, you're in. Gmail. Slack. Notion. Your company's internal dashboard.
No password prompts. No "Forgot password?" emails. No credential storage scattered across platforms.
That's Single Sign-On doing its job.
Most engineers treat SSO like a black box. Paste some OAuth config, wire it up, ship it.
But understanding the actual mechanism, the redirects, the tokens, the trust model, changes how you debug auth failures and architect identity systems.
Let's break it down.
The Problem SSO Solves
Before SSO, every app managed its own user database.
Your company uses 50 SaaS tools. Each needs:
Username and password
Separate account creation
Individual password resets
Independent access revocation
Employee leaves? IT manually revokes access in 50 systems. Miss one, and they keep access for months.
Password reuse means one breach compromises everything.
SSO's solution:
Centralize authentication at one Identity Provider (IdP).
User proves identity once. IdP issues a signed token. Every app trusts that token.
No passwords stored in individual apps. One place to manage access.
How SSO works?
The Core Mechanism
SSO works on a trust relationship between two parties:
Identity Provider (IdP): Stores credentials and handles authentication (Google, Okta, Azure AD).
Service Provider (SP): The app you want to access (Slack, GitHub, your SaaS product).
The trust is established through certificate exchange.
IdP signs tokens with its private key. Service Providers verify those signatures using the IdP's public key.
The flow:
User authenticates → IdP issues signed token → App verifies signature → Access granted.
Tamper with the token? Signature breaks. App rejects it.
What Happens When You Click "Sign In With Google"
Step 1: Access Request
You visit app.example.com. Not authenticated yet.
Step 2: Redirect to IdP
App redirects your browser to Google with:
Client ID (identifies the app)
Redirect URI (where to send you back)
Scope (what permissions it wants)
Step 3: Already Logged In?
Google checks if you're already authenticated.
Yes? Skip login. This is the "single" in Single Sign-On, authenticate once, access everything.
No? Show login screen.
Step 4: You Authenticate
You enter credentials at Google's domain, not the app's.
Critical: the app never sees your password.
Step 5: Token Issued
Google generates a signed token containing your identity (email, user ID, name).
Signs it with Google's private key to prove authenticity.
Redirects you back to app.example.com with the token.
Step 6: App Verifies and Grants Access
App verifies the signature using Google's public key.
Extracts your identity from the token.
Token valid? Session created. You're in.
Now when you visit other apps trusting Google, you're already authenticated.
What's Inside a Token
Tokens contain claims, key-value pairs of user data:
{
"sub": "user-12345",
"email": "[email protected]",
"name": "Jane Doe",
"iss": "https://accounts.google.com",
"aud": "your-app-client-id",
"exp": 1736472000
}Standard claims:
sub: Unique user IDiss: Which IdP issued thisaud: Which app it's forexp: When it expires
Custom claims: Your business logic (roles, permissions, tenant ID).
The token is cryptographically signed. Apps verify the signature to ensure it came from a trusted IdP and wasn't modified.
The Three Protocols
SAML 2.0: The Enterprise Standard
XML-based. Born in 2005.
IdP returns signed XML document → App parses XML → Access granted.
When to use: Enterprise B2B. Legacy corporate IdPs (Active Directory). Compliance-heavy environments.
Grants apps limited access to user resources without sharing passwords.
Critical: OAuth is authorization, not authentication.
Example: "Let Spotify access your Facebook friends list."
Spotify never gets your Facebook password. Facebook issues a token scoped to friends list access only.
When to use: Third-party integrations. API access delegation.
OpenID Connect (OIDC): OAuth + Identity
Extends OAuth 2.0 to add authentication.
Same OAuth flow, but IdP also returns an ID token (JWT) containing user identity.
JSON-based. Lighter than SAML. Better mobile support.
When to use: Modern SaaS apps. Consumer-facing authentication. Anywhere you need both "who the user is" and "what they can access"
Multi-Tenant SSO
Your SaaS supports multiple enterprise customers. Each has their own IdP.
Tenant A uses Okta. Tenant B uses Azure AD.
How it works:
Store the mapping: tenant_id → idp_issuer_url.
When user authenticates:
Verify token signature
Check token's
issmatches tenant's configured IdPGrant access
Prevents users from one tenant accessing another's data using a valid token from their own IdP.
Join 1,000+ engineers learning DevOps the hard way
Every week, I share:
How I'd approach problems differently (real projects, real mistakes)
Career moves that actually work (not LinkedIn motivational posts)
Technical deep-dives that change how you think about infrastructure
No fluff. No roadmaps. Just what works when you're building real systems.
👋 Find me on Twitter | Linkedin | Connect 1:1
Thank you for supporting this newsletter.
Y’all are the best.