- Service provider requests authentication
- Identity provider sends a SAML response with an assertion
- Service provider validates the assertion and creates its session
Write the requirement as an operation before choosing a protocol. “Employees must sign in through their organization’s identity provider” is a federation requirement. “The app must read a user’s calendar” is delegated API access. “The employee may approve an invoice” is your application’s authorization policy.
Those requirements can exist in one app. Giving all three the label “SSO” makes them harder to implement, because it hides the server responsible for each decision. The protocol choice gets clearer once the responsibilities are separated.
Compare the artifacts, not XML against JSON
SAML and OAuth aren’t equivalent packages with different serialization formats. SAML defines assertions and protocols around them; OAuth defines an authorization framework for obtaining resource access. This comparison concerns SAML’s browser single-sign-on use, not every capability in the SAML standard.
| Boundary | OAuth 2.0 | SAML 2.0 browser SSO |
|---|---|---|
| App’s role | Client requesting resource access | Service provider accepting identity evidence |
| Other party | Authorization server and resource API | Identity provider |
| Main credential | Access token for a resource server | Assertion intended for the service provider |
| Typical delivery | Code redirect, then token-endpoint exchange | Redirected authentication request, then browser POST response in a common binding |
| Enforcement | API checks token and allowed operation | Service provider validates assertion and creates local session |
| Local application permissions | Still your app’s responsibility | Still your app’s responsibility |
A SAML assertion can carry authentication statements and user attributes. A service provider may use those attributes in its own permission mapping, but an assertion isn’t automatically a bearer access token for an arbitrary REST API.
Likewise, an OAuth access token isn’t automatically a standardized login result. OIDC adds that identity contract, making OIDC versus SAML the more useful comparison when both candidates are being considered for sign-in.
SAML trust is configured before the browser arrives
SAML federation depends on an established relationship between the identity provider and service provider. The parties configure identifiers, endpoints, signing keys or certificates, and the expected assertion behavior. The service provider shouldn’t discover whom to trust by reading an untrusted incoming response.
In a service-provider-initiated flow, your app sends an authentication request through the browser. The identity provider authenticates the person under its policy and returns a response containing an assertion to the app’s assertion consumer service, often by an HTML form POST.
The app must validate the response according to its SAML profile and binding. That includes the trusted signature, issuer, intended audience, destination and recipient, time conditions, and correlation with the outstanding request. It must also prevent replay and consume the same signed assertion that it actually validated. XML signature handling makes that last requirement more subtle than a string comparison.
Use a maintained SAML implementation rather than assembling an XML parser and a signature helper into an improvised login handler. Microsoft Entra’s SAML protocol documentation shows how the response, subject confirmation, audience, and request correlation appear in a real provider contract.
Federation and delegation can coexist
An enterprise login doesn’t grant every external API permission the application might need. Once your app has a local session, an integration can separately ask the user to authorize access to another service through OAuth.
- Organization identity provider authenticates the employee through SAML.
- App maps the validated identity to an organization member and creates a local session.
- A separate OAuth grant authorizes a specific external API integration.
The organization identity and external service account may have different identifiers and even different email addresses. Connecting them should be an explicit action by the authenticated app user. Matching strings from two profiles doesn’t establish account ownership across systems.
The same separation helps with revocation. Disabling an external integration should stop its API calls. Terminating the local session should stop access to the app. Removing an employee from an identity provider may require additional application-session or provisioning behavior; it doesn’t magically erase every session the app previously created.
Choose what the identity provider and app can actually support
Use SAML when the organization’s federation contract requires it and your service provider can implement and maintain it correctly. That decision includes metadata exchange, certificate rotation, attribute mapping, tenant-specific configuration, and testing with the organization’s identity provider.
Use OIDC when both sides support it and you need the standardized OAuth-based identity layer. It gives you a different token and validation model, not an exemption from key rotation, tenant isolation, issuer validation, or session policy.
Use OAuth when the task is delegated resource access. The authorization code flow and PKCE references explain the redirect and proof mechanics for that task. Choosing SAML for login doesn’t remove the need for those mechanics if your app later needs an OAuth API integration.
Neither “SAML is old” nor “OIDC uses JWTs” is a sufficient security analysis. Inspect the accepted issuers, validation library, signed data, replay behavior, and operational configuration. A protocol name doesn’t compensate for trusting the wrong tenant or accepting a response intended for another app.
AnyOAuth’s current boundary is social sign-in
AnyOAuth currently supports Google and GitHub only. It isn’t a SAML identity provider or service-provider federation offering, and it isn’t a customer-facing OIDC provider. An enterprise SAML requirement therefore needs a separate supported integration.
If a buyer asks you to connect their organization’s SAML identity provider, don’t substitute a Google sign-in button. The requirement includes a federation relationship and often organization-specific configuration; a familiar personal account doesn’t supply those automatically.
For apps that need the supported social accounts, the docs explain the profile-to-session handoff. For enterprise federation, evaluate a maintained SAML integration or a platform offering that contract. The product label “auth” isn’t enough to tell you which one you’re getting.
If the vocabulary is getting crowded, what OAuth means separates resource access from login and local permissions. Start there, then select the protocol for each actual boundary instead of searching for one credential that does every job.
Sources
Primary and official references retrieved 2026-10-06:
- IETF, RFC 6749: The OAuth 2.0 Authorization Framework, especially §§1.1–1.4.
- IETF, RFC 9700: Best Current Practice for OAuth 2.0 Security, especially §2.
- OpenID Foundation, OpenID Connect Core 1.0, especially §§1–3.
- Microsoft, Single sign-on SAML protocol, especially Response, Subject, Conditions, and Audience.