What “Authentication” and “Authorization” actually mean

Authentication answers the question “who are you?” When you type your email and password into a website, and the website confirms it’s really you, that is authentication. Authorization answers a completely different question: “what are you allowed to do?” Once the website knows you are Priya, it still has to decide whether Priya is allowed to see the admin dashboard, download the finance report, or just view her own profile. People confuse these two words constantly, but keeping them separate in your head is the single most important skill for understanding this entire topic.

What is OAuth 2.0?

OAuth 2.0 is, at its heart, an authorization protocol. It was never designed to answer “who are you?” — it was designed to answer “can this app do this specific thing on your behalf, without you handing over your password?” OAuth 2.0 was created in 2012 by the Internet Engineering Task Force (IETF) after companies like Google, Twitter, and Facebook realized that letting third-party apps ask users for their actual passwords was a security disaster waiting to happen. Before OAuth, if you wanted a photo-printing website to grab your Facebook photos, you often had to type your real Facebook password directly into that photo-printing website. That website could then do literally anything with your account — read your messages, post as you, change your password. OAuth 2.0 replaced that with tokens: small, limited-permission “hall passes” that an app can use instead of your password.

What is OpenID Connect (OIDC)?

OpenID Connect, released in 2014, is a thin identity layer built directly on top of OAuth 2.0. OAuth 2.0 was so good at handling authorization that developers kept misusing it for authentication too, which caused subtle security bugs. OIDC fixed this by adding one crucial new piece: a standardized, verifiable proof of identity called an ID Token. If OAuth 2.0 hands out a hall pass that says “this app can read your calendar,” OIDC adds a second document that says “and by the way, this person is definitely john.smith@example.com, verified and signed by us.” This is exactly what powers every “Sign in with Google,” “Sign in with Microsoft,” or “Sign in with Apple” button you have ever clicked.

What is SAML?

SAML (Security Assertion Markup Language) is older than both — first published in 2002 and matured with SAML 2.0 in 2005 — and it grew up in a completely different world: large enterprises, banks, universities, and government agencies that needed employees to log in once and access dozens of internal, corporate-approved web applications without re-entering a password each time. This pattern is called Single Sign-On (SSO). SAML uses XML-based messages called assertions instead of the compact tokens used by OAuth and OIDC, and it was purpose-built for browser-based, enterprise environments, long before smartphones and mobile apps existed.

Key vocabulary you’ll see throughout this guide

• Identity Provider (IdP): The system that knows who you are and vouches for you — for example, Google, Okta, or your company’s Active Directory.
• Service Provider (SP) / Relying Party (RP): The application you’re trying to log into, which trusts the Identity Provider’s word.
• Token: A small, digitally signed piece of data that proves something — either who you are, or what you’re allowed to do.
• Assertion: SAML’s term for a signed statement about a user, similar in purpose to a token.
• Scope: A specific permission being requested, such as “read your email address” or “view your calendar.”

In every login flow you will ever look at, there are always three parties involved, no matter which protocol is used:

OAuth 2.0’s building blocks

• Resource Owner: The user who owns the protected data.
• Client: The application requesting access — this could be a web app, mobile app, or another server.
• Authorization Server: Issues access tokens after verifying the user and their consent.
• Resource Server: The API that actually holds the protected data (for example, an email API or a photo storage API) and checks incoming tokens before responding.

OpenID Connect’s building blocks

OIDC reuses every single piece of OAuth 2.0’s architecture and simply renames two of them to make their identity role clearer: the Authorization Server becomes the OpenID Provider (OP), and the Client becomes the Relying Party (RP) — the app that “relies” on the OpenID Provider’s word about who the user is. It also adds one new artifact: the ID Token, a compact, digitally signed package (in a format called a JWT, or JSON Web Token) that contains verified facts about the user.

SAML’s building blocks

• Principal: SAML’s name for the user.
• Identity Provider (IdP): The trusted system (like Okta, Azure AD, or Ping Identity) that authenticates the user and issues assertions.
• Service Provider (SP): The application the user wants to reach — Salesforce, Workday, an internal dashboard.
• SAML Assertion: An XML document, cryptographically signed by the IdP, stating “this user is authenticated, and here are their attributes.”

graph LR
    U["User / Browser"] -->|1 Requests access| CLIENT["Client App / Service Provider"]
    CLIENT -->|2 Redirects for login| AUTH["Authorization Server / Identity Provider"]
    U -->|3 Logs in and consents| AUTH
    AUTH -->|4 Issues Token or Assertion| CLIENT
    CLIENT -->|5 Presents token| API["Resource Server / Protected App"]
    API -->|6 Returns protected data| CLIENT
    

Notice how the diagram above never changes shape between the three protocols — only the labels and the format of the credential exchanged in step 4 (a compact token versus an XML assertion) actually differ. This shared skeleton is exactly why so many engineers get the three protocols confused: they are solving related problems using the same cast of characters.

How OAuth 2.0 works internally: the Authorization Code Flow

The most widely used and most secure OAuth 2.0 flow is the Authorization Code Flow. Picture a valet parking service at a hotel. You don’t hand the valet your house keys (your password) — you hand them a single car key (a limited, temporary token) that can only start your car and nothing else. In OAuth terms: the app redirects you to the Authorization Server, you log in and approve specific permissions (“this app wants to view your email address and calendar”), and the Authorization Server sends the app back a short-lived, one-time-use authorization code. The app then privately exchanges that code, behind the scenes, for an access token. The access token is what actually gets used to call APIs afterward.

How OpenID Connect works internally

OIDC reuses that exact same Authorization Code Flow, but adds one extra ingredient to the request: a scope called openid. When the app includes this scope, the OpenID Provider’s response now contains not just an access token, but also the ID Token — a signed JWT containing claims like the user’s unique ID (sub), email, name, and when they logged in. The application can cryptographically verify this token’s signature using the OpenID Provider’s public key, confirming it hasn’t been tampered with, without ever having to call an extra API. This is the single addition that turns “authorization” into “authentication.”

How SAML works internally

SAML’s internal mechanics look quite different because it predates modern token formats like JWT. When a user tries to reach a Service Provider (say, Salesforce) without being logged in yet, the Service Provider generates a SAML Authentication Request and redirects the user’s browser to the Identity Provider. The user authenticates there (often with a corporate username, password, and multi-factor authentication). The Identity Provider then builds a SAML Response, containing one or more signed XML assertions, and has the browser auto-submit an HTML form via POST back to the Service Provider. The Service Provider verifies the XML signature and, if valid, creates a session for the user — all within a few seconds, and often without the user noticing anything happened at all beyond a brief redirect.

sequenceDiagram
    participant Browser
    participant App as "Service Provider / App"
    participant IdP as "Identity Provider / Authorization Server"
    Browser->>App: 1 Try to access app
    App->>Browser: 2 Redirect to IdP for login
    Browser->>IdP: 3 Present login page
    Browser->>IdP: 4 Submit credentials, consent
    IdP->>Browser: 5 Return code or signed assertion
    Browser->>App: 6 Deliver code or assertion
    App->>IdP: 7 (OAuth/OIDC only) Exchange code for tokens
    IdP->>App: 8 Return access token and ID token
    App->>Browser: 9 Establish authenticated session
    

Why the “front-channel” versus “back-channel” distinction matters

OAuth 2.0 and OIDC’s Authorization Code Flow use two separate paths: the front-channel (through the user’s browser, visible and less trusted) delivers the authorization code, while the back-channel (a direct, server-to-server call, invisible to the browser) exchanges that code for tokens. This separation is a deliberate security decision — even if someone intercepts the browser traffic, they only get a short-lived code, not the actual access token. SAML, by contrast, traditionally sends its assertion straight through the front-channel via the browser, relying entirely on digital signatures and short validity windows to stay safe.

The lifecycle of an OAuth 2.0 access token

1. Issuance: The Authorization Server creates the access token after the user consents to specific scopes.
2. Usage: The Client attaches the token to every API request, typically in an HTTP header.
3. Validation: The Resource Server checks the token’s signature, expiration, and scopes before responding.
4. Expiration: Access tokens are deliberately short-lived — often just 15 minutes to an hour — to limit the damage if one is ever stolen.
5. Refresh: A longer-lived refresh token can be exchanged for a brand-new access token without asking the user to log in again, keeping the session alive quietly in the background.
6. Revocation: The user, an administrator, or the app itself can revoke a token early, immediately cutting off access.

The lifecycle of an OIDC ID Token

The ID Token behaves differently from the access token, because its job is proving a single moment in time, not ongoing access. It typically has a short lifespan too, and once the application reads the identity claims from it at login, it usually discards the ID Token entirely — the application then manages its own session (often with a cookie) rather than continuing to pass the ID Token around.

The lifecycle of a SAML assertion

SAML assertions are designed to be used almost immediately and then discarded. They typically include tight time-based conditions — a NotBefore and NotOnOrAfter timestamp — often valid for only a few minutes, to prevent an intercepted assertion from being replayed later by an attacker. After the Service Provider validates the assertion once and establishes a session, the assertion itself is not reused; the Service Provider’s own session cookie takes over for the rest of the visit.

Single Logout (SLO) — the forgotten half of the lifecycle

Enterprises using SAML often also care deeply about Single Logout: when a user logs out of one application, SAML can propagate that logout across every connected application in one action. This is a mature, well-standardized part of SAML. OIDC has an equivalent (called Front-Channel and Back-Channel Logout specifications), but it is less universally implemented in practice, and many OIDC-based systems still handle logout more loosely, simply by clearing local session cookies.

Common OAuth 2.0 / OIDC security concerns

• Authorization code interception: If an attacker captures the authorization code, they could try to exchange it for a token. This is why the industry standard now requires PKCE (Proof Key for Code Exchange) — a mechanism where the app generates a secret proof at the start of the flow, so only the same app that started the login can complete it.
• Redirect URI manipulation: If an Authorization Server doesn’t strictly validate where it’s allowed to redirect users back to, an attacker could trick it into sending a valid code to a malicious site instead.
• Token leakage: Storing access tokens insecurely (for example, in browser local storage where scripts can read them) exposes them to theft via cross-site scripting attacks.
• Missing nonce validation (OIDC-specific): The ID Token includes a nonce value the app sent earlier — skipping its verification opens the door to replay attacks.

Common SAML security concerns

• XML Signature Wrapping attacks: A historically serious class of vulnerability where attackers manipulate the XML structure so that a validly signed portion of the document appears to say something it doesn’t. Modern SAML libraries defend against this, but poorly implemented ones remain vulnerable.
• Assertion replay: Without proper time-window and one-time-use enforcement, a captured assertion could theoretically be reused.
• Weak XML parsing configuration: Misconfigured XML parsers can be tricked into disclosing internal files (an XML External Entity, or XXE, attack) if not hardened.

Shared security best practices across all three

• Always use HTTPS/TLS for every step of the exchange — never allow tokens or assertions to travel unencrypted.
• Keep token and assertion lifetimes as short as practically possible.
• Validate signatures, issuers, and audiences on every token or assertion received — never trust a token just because it “looks right.”
• Rotate signing keys periodically and support key rollover without downtime.

What to log

• Authentication attempts: Every login success and failure, with timestamps, source IP, and the application involved — never the password or full token itself.
• Token issuance and refresh events: When access tokens and refresh tokens are minted, and which scopes were granted.
• Consent decisions: When a user approves or denies an app’s requested permissions.
• Assertion validation outcomes (SAML): Whether signature checks passed or failed, and why.
• Revocation and logout events: When tokens are invalidated or a Single Logout is triggered.

Metrics worth tracking

Certificate and key expiry — the silent enterprise outage

One of the most common real-world outages in SAML deployments has nothing to do with hackers at all: it’s an expired signing certificate. Because SAML certificates are often set up once during initial integration and forgotten, teams frequently discover an expiry only when logins suddenly stop working company-wide. Mature organizations set automated alerts 30-60 days before certificate expiration for exactly this reason, for both SAML certificates and OIDC’s signing keys (published in a JSON Web Key Set, or JWKS).

Recommended design patterns

• Authorization Code Flow with PKCE: The current best-practice OAuth/OIDC flow for essentially every type of app, including mobile and single-page apps.
• Backend-for-Frontend (BFF): Keep tokens on a server the browser never directly touches, issuing the browser only a secure, HTTP-only session cookie instead.
• Federation broker pattern: Use a central Identity Provider (like Okta or Azure AD) that itself federates to Google, SAML-based enterprise directories, and social logins, so each individual app only has to integrate with one Identity Provider.
• Least-privilege scopes: Request the smallest set of OAuth scopes an app genuinely needs, and nothing more.

Other common anti-patterns

• The Implicit Flow (deprecated): An older OAuth flow that returned tokens directly in the browser’s URL fragment. It’s now discouraged industry-wide in favor of the Authorization Code Flow with PKCE, because tokens in URLs can leak through browser history and referrer headers.
• Storing tokens in browser local storage: Convenient for developers, but exposed to any malicious script that manages to run on the page (cross-site scripting).
• Skipping audience validation on SAML assertions: Accepting any validly signed assertion, regardless of who it was intended for, can let an assertion meant for one app be replayed against a different one.

Best practices

• Always validate token/assertion issuer, audience, and expiration — every single time, on every service that receives one.
• Use short-lived access tokens paired with securely stored, revocable refresh tokens.
• Prefer OpenID Connect over raw OAuth 2.0 whenever the actual goal is “log the user in,” not just “call an API.”
• Rotate signing keys and certificates on a schedule, and automate expiry alerts well in advance.
• Log authentication events without ever logging the tokens, passwords, or assertions themselves in plain text.
• Choose SAML for established enterprise SSO ecosystems; choose OIDC for new consumer products and modern APIs — and know that many identity platforms now support translating between the two automatically.

Common mistakes teams actually make

No. OpenID Connect is built directly on top of OAuth 2.0 — it doesn’t replace it, it extends it with an identity layer. Every OIDC flow is technically also a valid OAuth 2.0 flow underneath.

Yes, and this is extremely common. Many organizations use SAML for internal enterprise SSO across corporate applications, while simultaneously using OAuth 2.0/OIDC for API access and modern customer-facing products.

SAML relies heavily on full-page browser redirects and posting HTML forms, which fits poorly into native mobile app experiences. OAuth 2.0 and OIDC, with their lightweight JSON tokens and mobile-specific flows, were designed with this exact use case in mind.

An ID Token is a signed, verifiable statement about who the user is, meant to be read by the application itself. An access token is a credential meant to be presented to an API, and by design, applications generally should not try to inspect its contents.

Not inherently — each one’s real-world security depends far more on correct implementation (proper signature validation, short token lifetimes, PKCE, certificate rotation) than on which protocol was chosen in the first place.