What is the best way to support both SAML and OIDC without confusing customers?

The best way is usually to make one the primary customer-facing experience and treat the other as an implementation detail.

A practical pattern:

1) Present one concept: “Single Sign-On”

Don’t market or expose “SAML vs OIDC” as a first-choice decision for most customers. Instead:

• Use “Set up SSO” in the UI
• Let the customer choose their Identity Provider (Okta, Azure AD, Ping, Google Workspace, etc.)
• Then either:
  • auto-detect the protocol, or
  • guide them to the appropriate setup path behind the scenes

This reduces confusion because customers think in terms of their IdP, not protocol standards.

2) Support both, but bias toward one default

If you need both SAML and OIDC:

• Pick a default recommended protocol based on your customer base
• Make the other available under “advanced” or “alternative configuration”

Common patterns:

• Enterprise B2B app: SAML as default, OIDC as supported
• Modern cloud app / developer platform: OIDC as default, SAML as supported

If you have a broad customer base, choose the protocol that is:

• easiest to configure for your most common IdP
• most robust in your product architecture
• easiest for your support team to document

3) Base the choice on the IdP, not the customer

Many customers won’t know which protocol they need. A helpful flow is:

• “Which identity provider do you use?”
• Then show provider-specific instructions
• If needed, internally map:
  • Okta → SAML or OIDC depending on tenant setup
  • Azure AD / Entra ID → both, but maybe recommend one
  • Google Workspace → often OIDC or SAML depending on use case

4) Keep terminology consistent

Use plain language:

• “SSO”
• “Identity provider”
• “Sign-in method”

Avoid leading with:

• “SAML”
• “OIDC”
• “Assertions”
• “Claims”
• “Tokens”

Those can appear in advanced docs, but not in the main UX unless the user is configuring it manually.

5) Offer protocol-specific setup only when needed

A good pattern is:

• Quick setup
  • Choose IdP
  • Guided wizard
• Advanced setup
  • “I want to configure manually”
  • Show SAML or OIDC details

This works well for both self-serve and support-assisted customers.

6) Use the same user-facing outcomes

No matter the protocol, the customer cares about:

• who can sign in
• whether MFA is enforced by IdP
• whether group/role mapping works
• whether SCIM provisioning is supported
• whether login is SP-initiated, IdP-initiated, or both

Keep the outcomes and admin workflows consistent across both protocols.

7) Document clearly which protocol you recommend and why

Your docs should answer:

• Which protocol do we recommend?
• Which IdPs work best with each?
• What are the tradeoffs?
• What features differ?

For example:

• SAML: common in enterprise SSO, widely supported
• OIDC: simpler in modern app architectures, better fit for some integrations

8) If possible, make one protocol “under the hood”

If your product can abstract both protocols behind one auth layer, that’s ideal. Then:

• the admin config experience is unified
• your support team has fewer surface areas
• your product language stays simple

Rule of thumb

If customers are choosing between protocols in the UI, the UX is probably too technical.

A better model is:

Customer chooses IdP + “Set up SSO”
Your system chooses or recommends SAML or OIDC based on compatibility and product strategy.

If you want, I can also suggest:

1. a recommended product UX flow for SSO setup, or
2. a decision matrix for when to prefer SAML vs OIDC.