OAuth, OIDC, SAML, SSO, and JWT: A Beginner’s Guide to How Login Actually Works

If you have clicked “Sign in with Google,” connected Spotify to a third-party app, or opened your work laptop and found every internal tool already logged in, you have used several authentication protocols without knowing it. Their names (OAuth, OIDC, SAML, SSO, JWT) are often used loosely and interchangeably, which makes them confusing.

This guide explains what each one does, how they fit together, and where you will meet them as a developer.

First, clear up a common confusion

Two kinds of “permission requests” look alike, but they are completely different systems.

Device permissions are not OAuth. When a phone app asks “Allow access to your photos?”, that prompt comes from the operating system (iOS or Android), not from a login protocol. The OS guards hardware and local data: camera, microphone, photo library, location, contacts, and notifications. The app is reaching into your phone.

OAuth 2.0 is about online accounts. When a website says “Connect your Instagram account” and then pulls in your posts, that is OAuth 2.0. One online service is reaching into your account on another service’s servers.

Real examples of the OAuth kind:

• Scheduling tools like Later or Buffer connecting to an Instagram business or creator account through Meta’s Instagram API.
• A party-playlist app reading your playlists through the Spotify Web API.
• Automation tools like Zapier connecting Gmail, Slack, and Trello so they can work together.
• A marketplace using Stripe Connect to handle payments on a seller’s behalf.

Rule of thumb: if an app is reaching into your phone, it is an OS permission. If one online account is reaching into another online account, it is OAuth.

A mental model: the hotel

Picture a hotel. You are the guest. The front desk is the identity server. Your room key card is a token, a temporary pass. The rooms, gym, and pool are the apps and APIs you want to use.

You check in once. The front desk checks your ID and hands you a key card. The gym door does not ask for your passport again; it just reads the card. The card stops working at checkout, and if someone steals it, they can use it until then.

That picture shows the two ideas this whole topic depends on:

• Authentication answers “Who are you?” It is showing your ID at the front desk.
• Authorization answers “What are you allowed to do?” It is which doors your card opens.

Keep them separate in your head. Most confusion about these protocols comes from mixing them up.

OAuth 2.0: delegated access

OAuth 2.0 lets one app access your data, or act for you, on another service, without you ever giving that app your password.

A walkthrough: connecting a playlist app to Spotify

Imagine a third-party app called “MoodMixer.”

1. You click Connect Spotify in MoodMixer.
2. MoodMixer sends your browser to Spotify’s own login page at accounts.spotify.com.
3. Spotify shows a consent screen listing what MoodMixer wants, such as reading your private playlists and your top artists. These specific permissions are called scopes.
4. You click Agree.
5. Spotify sends MoodMixer a short-lived authorization code, which MoodMixer exchanges for an access token.
6. MoodMixer calls the Spotify Web API with the token in a request header: Authorization: Bearer <access_token>.

MoodMixer never sees your Spotify password. The token only permits what you approved, so it can read your playlists but cannot delete them.

The vocabulary you will see in documentation

• Access token: the key card sent with each API request. It is usually short-lived.
• Refresh token: lets the app get a new access token without asking you to approve again.
• Scopes: the exact permissions granted.
• Authorization server: the system that issues tokens, such as Spotify’s or Google’s login service.
• Resource server: the API that holds your data, such as the Spotify Web API.

Where developers meet OAuth 2.0

You will run into it when building on Google APIs (Gmail, Drive, Calendar), GitHub OAuth Apps and GitHub Apps, Slack apps, Discord bots, Shopify apps, and Stripe Connect. Check each provider’s documentation for the exact flows it supports.

OpenID Connect (OIDC): real login

OAuth 2.0 on its own does not tell an app (Moodmixer in our case) who you are. An access token says “this token may read playlists,” not “this token belongs to Alice.” That makes plain OAuth 2.0 the wrong tool for logging users in.

OpenID Connect fixes this. It is a layer on top of OAuth 2.0 that adds one key thing: an ID token, a signed statement of who the user is.

A walkthrough: “Sign in with Google”

1. An app shows a Sign in with Google button.
2. You click it, sign in at Google, and approve.
3. The app receives two tokens: an access token (the OAuth part, for calling Google APIs) and an ID token (the OIDC part, identifying you).
4. The app verifies the ID token and logs you in.

What is inside an ID token

Decoded, an ID token looks something like this:

{
  "iss": "https://accounts.google.com",
  "sub": "117...",
  "aud": "your-app-client-id.apps.googleusercontent.com",
  "email": "alice@gmail.com",
  "name": "Alice Chen",
  "iat": 1735686000,
  "exp": 1735689600
}

Before trusting the token, the app must check its signature, issuer, audience, and expiry.

The rule to remember

• Logging a user in? Use OIDC. You want the ID token.
• Calling an API on the user’s behalf? Use OAuth 2.0. You want the access token.

OAuth 1.0: the complicated ancestor

It powered early integrations with services like Twitter, Flickr, and Tumblr.

The big difference from 2.0: every API request had to be cryptographically signed. That stopped requests from being forged or tampered with even over plain HTTP, though the data itself was not encrypted. It was also notoriously fiddly. One misplaced character in the “signature base string” and requests failed.

OAuth 2.0 requires HTTPS for transport security and uses bearer tokens, where whoever holds the token can use it. Being far easier to implement, it became the standard.

SAML 2.0: enterprise single sign-on

SAML lets employees log into all their work apps after one login. SAML 2.0 is XML-based and remains a mainstay of corporate IT. Under the hood, SAML is a general way for one system to send another a signed statement about a user: who they are, how they logged in, and details like their email or role. Single sign-on is simply its most common use, especially in enterprises.

A walkthrough: your first day at a new job

1. Your company uses a central Identity Provider (IdP) such as Okta, Microsoft Entra ID (formerly Azure AD), OneLogin, or Ping Identity.
2. You open Salesforce, which acts as the Service Provider (SP).
3. Salesforce redirects your browser to the IdP.
4. Once you are signed in there, the IdP produces a digitally signed XML document called a SAML assertion. It states who you are and can include details like your department.
5. Your browser posts that assertion back to Salesforce, which verifies the IdP’s signature and lets you in.
6. When you open Slack, Zoom, or Workday next, you get in without typing a password again. That is single sign-on.

SAML or OIDC?

Both handle login and single sign-on. OIDC is the natural choice for new consumer, mobile, and API-driven apps, because it uses lightweight JSON and works well on mobile. SAML is often required when you integrate with a large organization’s existing employee login.

In practice, many enterprise products support both, and IdPs like Okta and Entra ID speak both protocols.

SSO: log in once, get in everywhere

SSO is not a protocol. It is what happens when many apps trust one central login server.

OIDC or SAML handles a single handoff: the moment an app sends you to the login server and gets an answer back. The “logged in everywhere” effect comes from the central server remembering you.

Why cookies are not shared between apps

Browsers scope cookies to a domain, so app-one.com cannot read a cookie set by app-two.com. (Subdomains of one domain, such as a.example.com and b.example.com, can share a cookie, but separate domains cannot.) SSO does not work around this rule. It relies on the central server's cookie instead, and each app then sets its own session after the redirect.

The hard part: single logout

Logging out everywhere does not come for free. Ideally, logging out of one app ends the central session and signs you out of every other app too, but you have to build this on purpose.

OpenID Connect defines three specifications for it:

• RP-Initiated Logout: the app tells the central server to log the user out.
• Back-Channel Logout: the central server calls each app directly, server to server, to end its session. It is the most reliable option and the most work to implement.

SAML has its own equivalent, called Single Logout (SLO).

JWT: a token format, not a protocol

A JSON Web Token (JWT) is a format that tokens can be written in.

Think of a JWT as a tamper-evident ticket. Anyone can read what is printed on it, but a signature proves it is genuine. Change “economy” to “first class” and the signature no longer matches, so the ticket is rejected.

A signed JWT has three parts separated by dots: header.payload.signature.

eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJBbGljZSIsImV4cCI6MTczNTY4OTYwMH0.Xf7z9K...

• Header: how the token is signed. The example decodes to {"alg":"RS256"}.
• Payload: the claims, such as who the user is and when the token expires. The example decodes to {"sub":"Alice","exp":1735689600}.
• Signature: the proof that the header and payload have not been changed.

An important caution: the header and payload are only Base64URL-encoded, not encrypted. Anyone who has the token can decode and read it, so never put secrets in a JWT payload.

Where you will see JWTs: every OIDC ID token is a JWT, and Firebase Authentication issues JWTs as well. Many OAuth access tokens are JWTs too, but not all; some providers, including Google, issue opaque access tokens that only the provider can interpret.

The one-sentence summary

OIDC proves who you are. OAuth 2.0 grants what an app may do on your behalf. SAML is the older enterprise way to prove who you are. JWT is a common format those tokens are written in.

If this helped, follow for more beginner-friendly guides to how the web really works.