OAuth and OIDC client configuration: do's and don'ts
Updated 2026-05-06
OAuth 2.0 and OIDC are decade-mature standards, but their defaults are not all safe and their flexibility makes misconfiguration easy. OAuth 2.1's consolidation tightens the safe defaults; the do's and don'ts here are a checklist for client configuration in 2026.
For protocol context, see the OAuth 2.1 explained guide and the enterprise SSO guide for SAML vs OIDC selection in B2B SaaS contexts.
Do
Use Authorization Code flow with PKCE for every client type
Authorization Code with PKCE is the OAuth 2.1 default for both public clients (mobile apps, SPAs) and confidential clients (server-side apps). One flow, fewer mistakes, harder to misuse.
OAuth 2.1 specification mandates PKCE for all clients. The Implicit and Resource Owner Password Credentials grants are explicitly removed. SPAs that still use Implicit are running deprecated patterns and should migrate.
Pre-register exact-match redirect URIs
Wildcard or prefix-matched redirect URIs have been the source of multiple production CVEs. Exact-match comparison removes the entire class of redirect URI attacks.
OAuth 2.1 specification requires exact-match redirect URI comparison. Multiple disclosed vulnerabilities (open-redirect plus OAuth = token theft) traced to lax redirect URI matching in older OAuth 2.0 deployments.
Pin the JWT signing algorithm explicitly when validating tokens
Some libraries default to accepting whatever algorithm the token claims (alg header), which permits algorithm-substitution attacks. Pin the expected algorithm at validation time.
Multiple JWT library CVEs have traced to algorithm-substitution attacks (RS256 token validated as HS256 using the public key as the HMAC secret). Always pin alg=RS256 (or your chosen algorithm) at validation.
Use Pushed Authorization Requests (PAR) for high-security flows
PAR moves the authorization request from URL parameters to a backend POST, returning a one-time request URI. It eliminates URL-tampering attacks and keeps sensitive parameters off the wire.
Required by FAPI (Financial-grade API) profiles for banking and high-security scenarios; recommended by OAuth 2.1 for any deployment with sensitive scopes. Supported by Curity, Auth0, Ory, and other OAuth-spec-purist platforms.
Don't
Don't use the Implicit grant for new SPAs
Implicit returns the access token in the URL fragment, which leaks via browser history, referrer headers, and logging. Authorization Code with PKCE handles the same client model without the leak surface.
OAuth 2.1 explicitly removes Implicit. Major OAuth libraries (Auth0, Okta, Microsoft, Google) deprecated Implicit through 2023–2025; the IETF draft considers it a known-vulnerable pattern.
Don't use the Resource Owner Password Credentials (ROPC) grant
ROPC has the client collect the user's password and POST it to the token endpoint, undermining the entire phishing-resistance story of OAuth. Designed for legacy migration, routinely misused.
OAuth 2.1 explicitly removes ROPC. For legacy migration scenarios, modern CIAM ship bulk-import tooling that doesn't require ROPC. For password-based auth where federation isn't available, use Authorization Code, not ROPC.
Don't pass tokens in URL query parameters
Tokens in URLs leak via browser history, server logs, referrer headers, and bookmarks. Bearer tokens belong in the Authorization header (preferred) or POST body, never in URLs.
OAuth 2.1 forbids bearer tokens in URLs. Multiple production token leaks have traced to this pattern, including via referrer headers when users navigate from authenticated pages to external sites.
Don't trust unverified ID tokens
An ID token must have its signature verified, its issuer confirmed, its audience checked, and its expiry validated. Skipping any of these turns an unverified JWT into authentication bypass.
OWASP JWT Cheat Sheet and OIDC specification both enumerate the validation requirements. Multiple production bypasses (Auth0 authorization-bypass 2022, several smaller incidents) have traced to skipped audience or issuer validation.