Do I need OIDC instead of SAML for a new app?

Not always — but for a new app, OIDC is usually the default choice unless you have a specific reason to use SAML.

Rule of thumb

• Choose OIDC if you’re building a modern web app, mobile app, SPA, or API-backed app.
• Choose SAML if you need to integrate with older enterprise identity systems, especially for SSO with corporate IdPs that already standardize on SAML.

Why OIDC is often better for new apps

• Built on OAuth 2.0 and JSON/JWT, which fits modern web/mobile/API architectures
• Simpler to implement than SAML in many cases
• Better support for:
  • SPAs
  • mobile apps
  • native apps
  • APIs / microservices
• Easier to work with standard libraries and cloud identity providers

When SAML is still useful

• Your customers are enterprises that already use SAML-based SSO
• You need to integrate with legacy IdPs like older ADFS/Shibboleth deployments
• A procurement/security requirement explicitly says “must support SAML”

Practical advice

If you’re designing a new authentication flow:

• Implement OIDC as your primary protocol
• Consider adding SAML only if customers ask for it

Common exception

If your app is only a backend service talking to another service, you may not need either directly — you might use:

• OAuth 2.0 client credentials
• service accounts
• mTLS
• workload identity

If you want, I can help you decide based on your app type (SPA, mobile, web app, API, enterprise B2B, etc.).