Before OIDC, There Was SAML
While OIDC is the modern standard for web and mobile apps, SAML (Security Assertion Markup Language) is still heavily used in large enterprise environments, particularly for Single Sign-On (SSO) to internal applications. If your company uses an internal portal to access legacy database administration tools, HR systems, or ERP software, it is almost certainly using SAML.
SAML was standardized in 2002 — long before smartphones and REST APIs existed. Its design reflects that era: it is XML-based, verbose, and built around browser redirects rather than API calls.
How SAML Works
SAML involves three parties:
- Principal: The user trying to log in.
- Identity Provider (IdP): The trusted authority that authenticates the user (e.g., your corporate Active Directory Federation Services, Okta, or Azure AD).
- Service Provider (SP): The application the user wants to access (e.g., a legacy database admin portal).
The flow:
- The user tries to access the Service Provider (the admin portal).
- The SP redirects the user's browser to the IdP with a SAML Authentication Request (an XML document, Base64-encoded in the URL).
- The user authenticates with the IdP (corporate SSO login).
- The IdP generates a SAML Assertion — a cryptographically signed XML document that states: "I assert that this user is
[email protected], authenticated at this timestamp, and is a member of thedb_admingroup." - The IdP posts this assertion back to the SP via the user's browser.
- The SP validates the XML signature using the IdP's public certificate, trusts the assertion, and grants access.
SAML vs. OIDC: When to Use Which
| Dimension | SAML | OIDC |
|---|---|---|
| Format | XML | JSON / JWT |
| Primary use case | Enterprise SSO, legacy apps | Modern web/mobile apps, APIs |
| Complexity | High (XML parsing, complex spec) | Lower (JSON, simpler flows) |
| Mobile support | Poor (browser-redirect heavy) | Excellent |
| API-native | No | Yes |
The practical rule: If you're building something new, use OIDC. If you're integrating with an existing enterprise system that only speaks SAML, you use SAML — or you put an identity broker (like Keycloak) in front that speaks both.
A common interview scenario: "Your company is acquiring a startup. Your IdP is Okta (OIDC/SAML). The startup uses a legacy on-prem app that only supports SAML. How do you integrate them?" The answer: configure Okta as the SAML Identity Provider for the legacy app. Okta handles the SAML assertion generation after authenticating users via your existing Okta directory. No changes needed to the legacy app — it just needs to trust Okta's signing certificate.