OAuth 2.0 and OpenID Connect

Alice: Welcome back to Security for Legal SaaS. I’m Alice.

Dan: And I’m Dan. Episode 20 — OAuth 2.0 and OpenID Connect. Alice, we just spent two episodes on sessions and JWTs. Now we’re talking about delegated authentication. Why should a legal SaaS platform care about OAuth?

Alice: Because every law firm already has an identity provider — an IdP, the system that manages user accounts and logins. Active Directory, Azure AD, Google Workspace, Okta. When you ask lawyers to create a separate username and password for your platform, three things happen. They reuse a password from somewhere else. They forget it regularly and trigger recovery flows. And when they leave the firm, nobody remembers to deactivate their account on your platform. OAuth and OIDC solve all three problems by delegating authentication to the firm’s existing identity infrastructure.

Dan: Let’s get the terminology straight. OAuth versus OIDC — what’s the difference?

Alice: OAuth 2.0 is an authorization framework. It answers “what is this application allowed to do on behalf of the user?” It was designed for delegated access — letting a third-party app access your Google Drive files without giving it your Google password. OpenID Connect — OIDC — is an authentication layer built on top of OAuth 2.0. It answers “who is this user?” It adds an ID token — a JWT containing identity claims like name, email, and a stable user identifier.

Dan: So if I just use OAuth 2.0 for login, that’s wrong?

Alice: It’s a documented anti-pattern. OAuth alone gives you an access token — which proves the user authorized your app to access a resource. But it doesn’t reliably tell you who the user is. The access token might have been issued to a different application. It might not contain identity claims. Using it for authentication leads to confused deputy problems — where an attacker tricks your service into misusing its authority on their behalf — and token injection attacks. Always use OIDC when you need to verify identity. The ID token is specifically designed for that purpose, with validation rules that prevent the attacks raw OAuth is vulnerable to.

Dan: Walk me through the recommended flow.

Alice: Authorization Code with PKCE — Proof Key for Code Exchange. OAuth 2.1, which is in draft but being widely adopted, makes PKCE mandatory for all authorization code grants. Here’s how it works. Your application generates a random string called a code verifier — at least 43 characters. It computes a SHA-256 hash of that string — the code challenge. It sends the user to the authorization server with the code challenge included. The user authenticates. The authorization server redirects back with an authorization code. Your application sends the code plus the original code verifier to the token endpoint. The server hashes the verifier, confirms it matches the challenge, and only then issues tokens.

Dan: What does PKCE actually protect against?

Alice: Authorization code interception. Without PKCE, if an attacker intercepts the authorization code — through a compromised redirect URI, browser history, referrer headers, or a malicious app registered with the same custom URI scheme on mobile — they can exchange it for tokens. With PKCE, the code is useless without the code verifier, which never left your application’s memory. Only the legitimate client that started the flow can complete it.

Dan: What about the Implicit flow? I still see it in older documentation.

Alice: Dead. Deprecated. OAuth 2.1 formally removes it. The Implicit flow returned tokens directly in the URL fragment — which meant they appeared in browser history, were exposed to JavaScript on the page, and could leak through referrer headers. It existed because early browsers couldn’t make cross-origin POST requests for token exchange. That limitation no longer exists. There is no scenario where Implicit flow is appropriate for new development. If your legal SaaS still uses it, migrate to Authorization Code plus PKCE immediately.

Dan: How should tokens be stored in a single-page application — an SPA, where the entire app runs in the browser?

Alice: The best current practice is the Backend-for-Frontend pattern — BFF. Your SPA communicates with a thin backend service that holds all OAuth tokens server-side. The SPA itself uses a standard httpOnly session cookie to authenticate with its BFF. The BFF proxies API calls, attaching the access token from its server-side store. Tokens never exist in the browser — no localStorage, no sessionStorage, no JavaScript variables. If the page has an XSS vulnerability, the attacker cannot steal OAuth tokens because they aren’t there.

Dan: That adds a backend component for what might otherwise be a pure SPA.

Alice: It does. One lightweight service — often just a few hundred lines. The alternative is storing tokens in JavaScript memory — which works, but means every page refresh requires silent re-authentication. Or storing in localStorage — which means any XSS vulnerability gives the attacker your tokens. For legal SaaS handling privileged documents, the BFF cost is trivial compared to the risk of token exfiltration.

Dan: Let’s talk about scope minimisation. What scopes should a legal SaaS platform request?

Alice: The minimum required for the current operation. For login — openid and email. That’s it. You don’t need profile access. You don’t need offline access unless you genuinely need refresh tokens. You don’t need calendar read or drive access just because the OAuth provider offers them. Request additional scopes incrementally — when the user takes an action that requires broader access, prompt for the additional scope at that moment. This is called progressive consent.

Dan: What about service-to-service communication? No user involved.

Alice: Client Credentials flow. Your document processing service authenticates directly to the authorization server using its own client ID and secret — no user redirect, no browser interaction. It receives an access token scoped to exactly what that service needs — maybe documents:read and nothing else. Client secrets must be stored in a secrets manager, rotated quarterly, and never committed to version control. Obvious, but you’d be amazed how many client secrets live in environment variables copied from a Slack message three years ago.

Dan: Legal SaaS has some unique integration requirements. Court systems, bar associations, client identity providers.

Alice: Multi-tenant IdP routing is the key challenge. Your platform serves dozens of law firms. Each has their own Azure AD or Okta instance. When a user hits your login page, you need to determine which IdP to redirect them to. The standard pattern — type your email address, the system extracts the domain, looks up the tenant-to-IdP mapping, redirects to the correct authorization endpoint. On the return trip, you validate the ID token’s issuer claim matches the expected IdP for that tenant. This prevents IdP confusion — an attacker running their own IdP cannot issue tokens that your platform accepts for a different tenant.

Dan: What about integrating with court e-filing systems?

Alice: Jurisdictions are increasingly offering API access to e-filing systems for authorised legal tech providers. Singapore’s eLitigation, various US state courts. These typically use OAuth 2.0 with strict scope limitations — read case status but not file documents, for example. The security requirement is narrow scoping and comprehensive audit logging. Every access token obtained for court system interaction should be logged with the user who triggered it, the scopes granted, and the operations performed. Courts are understandably cautious about API access to their systems.

Dan: What are the most common OAuth implementation mistakes you see?

Alice: Five. One — open redirectors on the callback URL. If your redirect URI accepts arbitrary paths or has a wildcard, attackers can redirect the authorization code to their server. Use exact-match redirect URI validation only. Two — missing state parameter. The state parameter is a random value your app sends at the start of the OAuth flow and checks when it comes back, to prove the response matches the request. Without it, CSRF attacks can force a user to authenticate as the attacker. Three — accepting tokens from any issuer. Always validate the iss claim against your expected IdP. Four — storing client secrets in frontend code. SPAs are public clients — they cannot hold secrets. Use PKCE. Five — using access tokens for authentication instead of ID tokens. Access tokens are for API authorization. ID tokens are for identity verification. Conflating them opens you to token injection and confused deputy attacks — where your service acts on a forged identity because it trusted the wrong token type.

Dan: Next episode — Multi-Factor Authentication. Adding a second factor so that a compromised password alone isn’t game over.

Alice: Until then, I’m Alice.

Dan: And I’m Dan.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.