Learning Cactus

Why Authentication and SSO Feel Confusing — And How Everything Actually Connects

May 13, 2026

If you have ever felt confused between terms like:

  • SSO
  • OAuth 2.0
  • OIDC
  • SAML
  • Federation
  • JWT
  • Sessions
  • Cookies
  • Tokens
  • localStorage

…you are not alone.

For many developers, these concepts feel disconnected because they are often learned separately:

  • OAuth from API tutorials
  • JWT from backend authentication examples
  • SSO from enterprise applications
  • Cookies from browser discussions
  • Sessions from server-side frameworks

As a result, authentication starts feeling like a collection of random technologies instead of one connected system.

But the truth is, almost everything in modern authentication is built around a few core ideas. Once those ideas become clear, all the technologies begin to fit together naturally.

Questions Most Developers Have

Real Questions Developers Often Have

  • What exactly is SSO, and how does it work internally?
  • How does “Login with Google/GitHub” actually work?
  • Why can logging into one app automatically log users into another app?
  • How does Gmail login carry over to YouTube and other Google products?
  • How does the browser remember logged-in users?
  • What roles do cookies, sessions, tokens, and localStorage play?
  • What is the difference between JWT and session-based authentication?
  • What exactly are OAuth 2.0, OIDC, SAML, and federation?
  • How are all these concepts connected in real-world systems?

These are not separate topics. They are deeply interconnected parts of the same authentication ecosystem.

This blog will connect all of them together step by step.

The Real Goal of Authentication Systems

Modern authentication systems try to solve three major problems. Everything else evolves from these.

Problem 1 — Authentication

Authentication relates to - Who is the user?

Examples:

  • Logging in with username and password
  • Login with Google
  • Login with GitHub
  • Login with Microsoft

The system must verify identity. After successful authentication, the application knows:

This user is LearningCactus

Authentication is about identity verification.

Problem 2 — Authorization

Authorization answers: What is the user allowed to do?

Examples:

  • Can the user access admin APIs?
  • Can the user edit documents?
  • Can the user access billing information?
  • Can the user read patient records?

A user may be authenticated but still not authorized for certain operations.

For example: Authenticated user != Admin user

Authorization usually involves:

  • roles
  • permissions
  • scopes
  • policies

Problem 3 — Session Management

After login, another problem appears - How does the application remember the user?

Without session management:

  • Every page refresh would require login again
  • Every API call would need credentials again

This is where cookies, sessions, JWT tokens and browser storage start becoming important.

Understanding the Main Actors

Almost every modern authentication system contains three participants.

  1. User: The person trying to access the application.
    • A customer
    • An employee
    • A developer
    • An administrator
  2. The Client Application: The application the user is trying to access.

    3. Examples:

    • Spotify
    • Slack
    • YouTube
    • Notion
    • Your company portal

    These applications usually do not want to manage passwords directly.

  3. The Identity Provider (IdP): The system responsible for authenticating users.

    4. Examples:

    • Google
    • GitHub
    • Okta
    • Auth0
    • Microsoft Azure AD

    The Identity Provider becomes the trusted authority for verifying users.

The Most Important Modern Authentication Concept

Modern applications increasingly avoid handling passwords themselves. Instead, they delegate authentication to trusted providers.

For example, Spotify trusts Google to verify users.

This means:

  • Spotify does not need your Google password
  • Spotify simply trusts Google’s verification

This single idea is the foundation behind:

  • SSO
  • OAuth
  • OIDC
  • Federation

Understanding Login with Google

Consider a user opening Spotify and clicking, Login with Google. At first glance, this looks simple, but internally, several steps happen.

Let us try and understand the step by step flow of what happens behind the scene.

Step 1: User Opens Spotify - The user is required to authenticate. User selects Login with Google Spotify needs proof of identity.

Step 2: Spotify Redirects User to Google - Instead of asking for a password itself, Spotify redirects the user to Google. Why? Because Spotify trusts Google as an Identity Provider.

Step 3: Google Authenticates the User - Google checks:

  • email
  • password
  • multi-factor authentication
  • existing login session

If authentication succeeds, Google now knows, this is the correct user.

Step 4: Google Sends Identity Proof Back - Google sends authentication proof back to Spotify.

This proof may include:

  • identity token
  • authorization code
  • access token

depending on the protocol being used.

Step 5: Spotify Creates Login State - Spotify now trusts the user identity because Google verified it.

Spotify creates:

  • session
  • cookie
  • token

to keep the user logged in.

The Core Idea Behind SSO
Now consider another application thisismyworld.com on a browser. You logged in using GitHub.

Later you open, another web application thatisyourworld.com the same browser and choose - Login with GitHub. You are logged in and inside the application thatisyourworld.com, but how?

Why doesn't Github ask again for your credentials?

The Browser Already Has a GitHub Session
This is the key to understanding SSO. Earlier, when the user authenticated with GitHub, GitHub stored login state in the browser usually through cookies.

Something like:

github.com cookie:
session_id = session123

Later, another application redirects the user to GitHub again. The browser automatically sends GitHub’s cookies back to GitHub. GitHub sees, this user already authenticated earlier. So, Github skips the login screen.

This creates the SSO experience.

What SSO Actually Means

Authenticate once with a trusted Identity Provider and reuse that authenticated state across multiple applications.

Important detail to notice is that applications themselves are not directly sharing passwords or sessions. Instead, all applications trust the same Identity Provider and the browser carries authentication state between requests.

Why Gmail Login Automatically Works in YouTube
This question follows the same idea or principle. Applications like Gmail, Youtube, Google Drive, Google docs, etc. all trust the same Identity Provider - Google Accounts.

Once authenticated Google stores login state in browser cookies. When another Google service opens, it checks whether a Google authentication already exists.

If valid, the user is automatically logged in.

Cookies — The Backbone of Browser Authentication
Cookies are small pieces of data stored by browsers.

Example:

session_id = session123

A very important browser behaviour is that it automatically attach cookies to matching domains. This automatic behavior is one of the most important reasons SSO works smoothly.

Why Cookies Matter So Much
Cookies are commonly used to store:

  • session identifiers
  • authentication references
  • refresh tokens
  • login state

The cookie itself may not contain user data directly. Instead, it could store something like session_id(user session on server). The server maps the session identifier to actual user information.

Sessions Explained
A session in literal terms means, a server remembering the authenticated users.

As we saw earlier, the browser onlys stores the session identifier but the server stores:

  • user identity
  • expiration
  • roles
  • login state

Sessions are commonly stored in

  • memory
  • Redis
  • databases

Understanding JWT
JWT stands for JSON Web Token.

A JWT often contains:

user ID roles expiration permissions

Example structure: xxxxx.yyyyy.zzzzz

The token is digitally signed. This allows servers to verify authenticity without storing session data.

localStorage vs Cookies
These are frequently confused but they behave very differently.

localStorage is controlled by Javascript, manually accessed and not automatically sent to servers.

Example:

localStorage.setItem("token", jwt)

When using localStorage, applications must manually attach tokens to requests.

Example:

Authorization: Bearer jwt

Cookies, on the other hand, behave differently. Browsers automatically send cookies to requests. Exacmple:

Cookie: session=abc123

This automatic behavior is one reason cookies remain heavily used in authentication systems.

OAuth 2.0 — The Most Misunderstood Term
OAuth is often misunderstood as a login protocol. But OAuth primarily solves a different problem.

OAuth is about delegated authorization. Consider Canva accessing Google Drive, the user allows Canva to:

  • read files
  • upload files

without giving Canva the Google password. OAuth enables this secure permission delegation.

OAuth answers: 

What can this application access?

It is fundamentally about:

  • permissions
  • delegated access

not identity itself.

Then What is OIDC?
OIDC (OpenID Connect) extends OAuth. It adds the identity layer.

Now applications can know: 

who the user is

This is why: “Login with Google” “Login with GitHub”

usually use OIDC.

Simplified Difference
OAuth: What resources can the application access?

OIDC: Who is the user?

Federation
Federation means trusting the external identity systems. Instead of managing passwords internally, applications trust:

  • Google
  • Microsoft
  • Okta
  • Azure AD

Federation reduces:

  • password management complexity
  • security risks
  • duplicate identity systems

SAML
SAML is an older enterprise authentication protocol.

Common in:

  • banks
  • healthcare
  • enterprise corporate systems

Characteristics:

  • XML-based
  • enterprise-focused
  • older but still widely used

OIDC is generally considered the modern, lighter alternative.

How Everything Connects Together
At first, all these terms seem independent but they are actually connected layers. The complete modern authentication flow may look like:

User opens application
        ↓
Application redirects to Identity Provider
        ↓
Identity Provider authenticates user
        ↓
Identity Provider returns authentication proof
        ↓
Application trusts Identity Provider
        ↓
Application creates session/token
        ↓
Browser stores authentication state
        ↓
User stays logged in

The Central Idea That Connects Everything
Almost every authentication system can be understood by answering four questions:

  1. Who verifies identity?

    2. Examples:

    • Google
    • GitHub

    • Okta

  2. How is proof transferred?

    3. Examples:

    • cookies
    • JWT
    • authorization codes
    • tokens
  3. How is login remembered?

    4. Examples:

    • sessions
    • cookies
    • refresh tokens

  4. Who trusts whom?

    5. Examples:

    • Spotify trusts Google
    • Company apps trust Okta
    • Enterprise systems trust Azure AD

Today, many systems commonly use: 

OIDC + OAuth2 + JWT + Cookies

Examples:

  • Google Login
  • GitHub Login
  • Auth0
  • AWS Cognito
  • Okta

Final Mental Model
Authentication becomes much easier when viewed like this:

Identity Provider verifies users
Applications trust Identity Providers
Browsers carry authentication state
Protocols define communication rules
Tokens/cookies preserve login state

Once this model becomes clear, terms like:

  • OAuth
  • OIDC
  • SSO
  • JWT
  • SAML
  • Federation

stop feeling like isolated concepts and begin feeling like connected solutions to the same authentication problems.

More posts in this series coming soon.