Hi there! I'm Shrijith Venkatrama, founder of Hexmos. Right now, I’m building LiveAPI, a first of its kind tool for helping you automatically index API endpoints across all your repositories. LiveAPI helps you discover, understand and use APIs in large tech infrastructures with ease.

Authentication and authorization protocols can feel like navigating a maze. OAuth2, OpenID Connect (OIDC), and SAML are the big players, but choosing one depends on your app’s needs. This post breaks them down with examples, tables, and enough detail to help you decide without drowning in jargon. Let’s dive into what each protocol does, how they differ, and when to use them.

What Are These Protocols Anyway?

OAuth2 is an authorization framework. It lets users grant apps access to resources (like their Google Drive files) without sharing passwords. Think of it as a valet key for your app—it gives limited access to specific things.

OIDC (OpenID Connect) builds on OAuth2 but focuses on authentication. It verifies who the user is and provides info like their name or email. It’s like OAuth2 with an ID card.

SAML (Security Assertion Markup Language) is an older standard for single sign-on (SSO). It’s about securely exchanging user info between an identity provider (IdP) and a service provider (SP), often for enterprise apps.

Here’s a quick comparison:

Key takeaway: OAuth2 is for access, OIDC adds user identity, and SAML is for enterprise SSO. Let’s unpack each.

OAuth2: Granting Access Without Passwords

OAuth2 handles authorization—letting apps access resources on behalf of users. It uses access tokens to grant specific permissions (scopes). For example, a photo app might request access to your Google Photos but not your Gmail.

How It Works

1. User Consent: The user logs into an authorization server (e.g., Google) and approves the app’s request.
2. Access Token: The server issues a token the app uses to access resources.
3. API Calls: The app sends the token to the resource server (e.g., Google Photos API) to fetch data.

Example: OAuth2 in Node.js

Here’s a Node.js example using the express framework and axios to get an access token from GitHub’s OAuth2 flow. This uses the authorization code grant (common for web apps).

const express = require('express');
const axios = require('axios');
const app = express();

const CLIENT_ID = 'your_client_id'; // Replace with your GitHub app's client ID
const CLIENT_SECRET = 'your_client_secret'; // Replace with your GitHub app's client secret
const REDIRECT_URI = 'http://localhost:3000/callback';

app.get('/login', (req, res) => {
  res.redirect(`https://github.com/login/oauth/authorize?client_id=${CLIENT_ID}&redirect_uri=${REDIRECT_URI}`);
});

app.get('/callback', async (req, res) => {
  const code = req.query.code;
  try {
    const response = await axios.post('https://github.com/login/oauth/access_token', {
      client_id: CLIENT_ID,
      client_secret: CLIENT_SECRET,
      code: code,
    }, {
      headers: { Accept: 'application/json' }
    });
    const accessToken = response.data.access_token;
    res.send(`Access Token: ${accessToken}`);
    // Output: Access Token: gho_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  } catch (error) {
    res.status(500).send('Error fetching token');
  }
});

app.listen(3000, () => console.log('Server running on http://localhost:3000'));

Run it: Install dependencies (npm install express axios), replace CLIENT_ID and CLIENT_SECRET (get them from GitHub’s developer settings), and visit /login. After GitHub approval, you’ll see the access token.

Why OAuth2? It’s flexible for API-driven apps. Use it when you need to access user resources securely. OAuth2 RFC has the full spec.

OIDC: Adding Identity to OAuth2

OpenID Connect is OAuth2 with an identity layer. It’s for authentication—verifying who the user is and sharing info like their email or name via an ID token. It’s widely used for modern apps with social logins.

How It Differs from OAuth2

OIDC uses OAuth2’s flows but adds an ID token (a JWT—JSON Web Token) containing user info. You still get an access token for resources, but the ID token is for verifying identity.

Example: OIDC with Google

Here’s a Python Flask app using Google’s OIDC to authenticate users and fetch their profile info.

from flask import Flask, redirect, request
import requests

app = Flask(__name__)

CLIENT_ID = 'your_client_id'  # From Google Cloud Console
CLIENT_SECRET = 'your_client_secret'  # From Google Cloud Console
REDIRECT_URI = 'http://localhost:5000/callback'
AUTH_URL = 'https://accounts.google.com/o/oauth2/v2/auth'
TOKEN_URL = 'https://oauth2.googleapis.com/token'
USERINFO_URL = 'https://openidconnect.googleapis.com/v1/userinfo'

@app.route('/login')
def login():
    auth_params = {
        'client_id': CLIENT_ID,
        'redirect_uri': REDIRECT_URI,
        'response_type': 'code',
        'scope': 'openid email profile',
    }
    url = f'{AUTH_URL}?{'&'.join([f'{k}={v}' for k,v in auth_params.items()])}'
    return redirect(url)

@app.route('/callback')
def callback():
    code = request.args.get('code')
    token_data = {
        'code': code,
        'client_id': CLIENT_ID,
        'client_secret': CLIENT_SECRET,
        'redirect_uri': REDIRECT_URI,
        'grant_type': 'authorization_code',
    }
    response = requests.post(TOKEN_URL, data=token_data)
    tokens = response.json()
    id_token = tokens.get('id_token')
    access_token = tokens.get('access_token')
    headers = {'Authorization': f'Bearer {access_token}'}
    user_info = requests.get(USERINFO_URL, headers=headers).json()
    return f"User: {user_info['name']}, Email: {user_info['email']}"
    # Output: User: John Doe, Email: john.doe@example.com

if __name__ == '__main__':
    app.run(port=5000)

Run it: Install Flask and requests (pip install flask requests), set up a Google Cloud project for credentials, and run the app. Visit /login, sign in, and see user info.

Why OIDC? Use it for user authentication with social logins or when you need user details. Check OpenID Connect’s site for more.

SAML: The Enterprise SSO Veteran

SAML is designed for single sign-on in enterprises. It lets users log in once (via an IdP like Okta) and access multiple apps (SPs) without re-authenticating. It’s XML-based and common in corporate environments.

How It Works

1. User Requests Access: The user tries to access an app (SP).
2. Redirect to IdP: The app redirects them to the IdP for login.
3. SAML Assertion: The IdP sends an XML assertion with user info to the SP.
4. Access Granted: The SP trusts the assertion and logs the user in.

Example: SAML Assertion (Simplified)

Here’s a sample SAML response (not a full app, as SAML requires complex setup with tools like SimpleSAMLphp).

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="id123" IssueInstant="2025-07-24T23:04:00Z">
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <saml:Subject>
    <saml:NameID>user@example.com</saml:NameID>
  </saml:Subject>
  <saml:AuthnStatement AuthnInstant="2025-07-24T23:04:00Z">
    <saml:AuthnContext>
      <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>
</saml:Assertion>

Output: This XML tells the SP the user (user@example.com) is authenticated by the IdP.

Why SAML? It’s great for enterprise SSO where apps need to trust a central IdP. See SAML 2.0 specs for details.

Comparing Security Features

Security is critical. Here’s how they stack up:

Key takeaway: OAuth2 and OIDC rely on HTTPS and JSON, while SAML’s XML needs careful parsing to avoid attacks. Always validate tokens/assertions.

When to Use Each Protocol

Choosing depends on your app’s needs:

• OAuth2: Use for API authorization. Example: A mobile app accessing a user’s Spotify playlists.
• OIDC: Pick for user authentication with identity info. Example: Logging into a web app with Google.
• SAML: Go for enterprise SSO. Example: Employees accessing internal tools via Okta.

Tip: If you’re building a modern consumer app, OIDC is often the go-to for its simplicity and JSON-based flow.

Integration Complexity

OAuth2 and OIDC are easier thanks to JSON and robust libraries like passport.js or python-social-auth. SAML often requires heavy configuration and tools like SimpleSAMLphp. Auth0’s docs are a good starting point for OAuth2/OIDC.

Real-World Examples

• OAuth2: Twitter’s API uses OAuth2 for apps to post tweets on a user’s behalf.
• OIDC: Firebase Authentication uses OIDC for Google Sign-In, returning user info like email.
• SAML: Salesforce integrates with Okta for SSO, letting employees access it with one login.

Key takeaway: OAuth2 and OIDC dominate consumer apps; SAML rules in enterprises.

Making the Right Choice for Your App

Picking a protocol comes down to your use case. If you’re building a consumer-facing app with APIs, OAuth2 (or OIDC for authentication) is usually enough. For enterprise SSO, SAML is often mandated by IT teams. Consider your team’s expertise—JSON-based OAuth2/OIDC is easier than XML-heavy SAML. Always prioritize security (validate tokens, use HTTPS) and test your flows thoroughly.

Start with OAuth2/OIDC for modern apps unless your org requires SAML. Libraries and cloud providers (like Auth0 or Google) make setup straightforward. If you’re still unsure, prototype with OAuth2—it’s flexible and widely supported.