OAuth2 vs SAML

OAuth 2.0's core grant types (authorization code, client credentials, and others defined in RFC 6749) exist to answer 'can this application access this resource on the user's behalf,' with scopes controlling exactly what access is granted. Nothing in the base OAuth2 spec verifies the user's identity to the relying application — a common, genuine source of confusion, since many developers use 'OAuth login' loosely to mean something OAuth2 alone doesn't actually provide.

OpenID Connect closes that gap specifically: it adds a standardized ID token (a JWT containing identity claims like the user's subject identifier and authentication time) and a UserInfo endpoint, built as a defined extension on top of OAuth2's authorization flows. In practice, 'OAuth2 login' in a modern application almost always means OAuth2 + OIDC together, not OAuth2 alone.

SAML, by contrast, was designed from the outset as an authentication and identity-federation protocol — its assertions exist specifically to convey verified identity and attributes from an identity provider to a service provider, with no separate 'add identity later' layer required the way OAuth2 needed OIDC.

OAuth2/OIDC tokens are typically JSON — compact, easy to parse in virtually any language, and well-suited to mobile clients and JavaScript-heavy web apps. SAML assertions are XML, digitally signed (commonly using XML Signature/XMLDSig), a heavier but mature format with a long enterprise deployment history.

SAML's XML-based signing has a specific, well-documented historical vulnerability class worth knowing precisely: XML Signature Wrapping (XSW) attacks, where an attacker restructures a signed XML document (moving or duplicating signed elements) in a way that a naively-implemented parser validates the original signature against one part of the document while actually processing a different, attacker-modified part. This isn't a flaw in SAML's cryptography itself, but a real, repeatedly-demonstrated implementation pitfall in SAML consumers that don't carefully bind signature verification to the exact element being acted on — a genuine reason correct SAML library usage (not hand-rolled XML parsing) matters more than it might first appear.

OAuth2/OIDC's JSON-based tokens sidestep that specific attack class structurally, though they carry their own well-known pitfalls (algorithm-confusion attacks against JWT verification, covered in the HMAC vs Digital Signatures comparison, and the general JWT storage/XSS/CSRF considerations covered in JWT vs Session Cookies).

SAML's deep entrenchment in enterprise identity infrastructure isn't inertia alone — many large organizations' identity providers, compliance frameworks, and existing SSO integrations were built around SAML years before OIDC matured, and the cost of migrating a large enterprise's SSO integrations is genuinely high. Most enterprise identity providers today support both protocols simultaneously specifically because of this installed base.

OAuth2/OIDC's mobile- and API-friendly design (lightweight JSON, native support for public clients like mobile apps and single-page applications via PKCE, defined in RFC 7636) is why virtually every consumer-facing 'Sign in with Google/Apple/Microsoft' flow uses it rather than SAML — SAML's browser-redirect-and-XML model was never designed with native mobile app flows as a first-class concern the way modern OAuth2/OIDC extensions were.