- 01Both SAML 2.0 and OpenID Connect are mature, secure protocols when implemented properly. The choice is rarely about security and usually about application architecture, IdP support, and developer familiarity.
- 02OIDC is the default for new: JSON-based and REST-friendly, designed for both web and mobile-native apps, standard scopes for API token issuance, strong tooling across modern frameworks.
- 03SAML still wins for enterprise SaaS: many SaaS apps support SAML only or charge a premium for OIDC. Federation strategy must support both — typically via an IdP that natively brokers between protocols.
- 04Recurring mistakes from our IR work in the past 24 months: SAML response signature validation that does not actually validate (Golden SAML class), OIDC token validation missing audience/issuer checks, PKCE missing on public clients.
Both SAML 2.0 and OpenID Connect are mature, secure protocols when properly implemented. The choice between them is rarely about security and usually about the application's architecture, the IdP's support, and the developer's familiarity.
OIDC is the default for new
- 01JSON-based, REST-friendly, easier developer experience
- 02Designed for both web and mobile-native applications
- 03Standard scopes for token issuance for APIs
- 04Strong tooling across modern frameworks
SAML still wins for enterprise SaaS
The enterprise SaaS world standardized on SAML before OIDC matured. Many SaaS applications support SAML only, or charge a premium for OIDC. Your federation strategy must support both — typically by having an IdP that natively brokers between protocols.
Mistakes that recur
SAML response signature validation that does not actually validate (Golden SAML class). OIDC token validation that does not check audience or issuer. PKCE missing on public clients. Each of these has appeared in our incident response work in the past 24 months.