OAuth2, OIDC, SAML, UMA — When to Use Which (Enterprise Decision Framework)

I've lost count of how many times I've been asked: "Should we use SAML or OIDC?" or "Is OAuth2 enough, or do we need OIDC?" These aren't academic questions—choosing wrong can mean months of rework.

After implementing all four protocols (SAML, OAuth2, OIDC, UMA) in production for government and enterprise platforms, here's my practical decision framework.

Quick Reference

Protocol	Primary Use Case	Key Strength
SAML 2.0	Enterprise SSO	Mature, widely supported
OAuth2	API authorization	Delegated access, scopes
OIDC	Modern app authentication	Identity + tokens
UMA	Fine-grained authorization	Resource-level permissions

SAML 2.0: The Enterprise Workhorse

When to Use

• Enterprise workforce SSO (employees accessing internal apps)
• B2B partner integrations (legacy enterprise systems)
• Government portals with existing SAML infrastructure

When NOT to Use

• Mobile applications (too heavy)
• Consumer-facing apps (poor UX)
• Microservices architectures (token size issues)

Real-World Example

For our enterprise platform, we use SAML for:

• Employee access to Salesforce, Workday, ServiceNow
• Partner access to extranet applications
• Federation with government systems

<!-- SAML Assertion (simplified) -->
<saml:Assertion>
  <saml:Subject>
    <saml:NameID>user@enterprise.com</saml:NameID>
  </saml:Subject>
  <saml:AttributeStatement>
    <saml:Attribute Name="role">
      <saml:AttributeValue>admin</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Pros:

• Mature (20+ years)
• Strong security model
• Widely supported in enterprise software

Cons:

• XML-heavy (large payloads)
• Complex to implement from scratch
• Not mobile-friendly

OAuth2: API Authorization Done Right

When to Use

• API access delegation (third-party integrations)
• Machine-to-machine authentication (service accounts)
• Mobile/native apps accessing backend APIs

When NOT to Use

• User authentication (OAuth2 ≠ authentication!)
• When you need identity claims (use OIDC instead)

Real-World Example

Our API gateway uses OAuth2 for:

• Third-party developers accessing government APIs
• Internal microservices communication
• Mobile app backend integration

POST /oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=mobile-app
&client_secret=xxx
&scope=read:profile write:transactions

Pros:

• Flexible grant types
• Token-based (lightweight)
• Industry standard for API security

Cons:

• Doesn't provide identity (by itself)
• Complex security considerations
• Easy to implement incorrectly

OpenID Connect: OAuth2 + Identity

When to Use

• Consumer-facing applications (CIAM)
• Mobile app authentication
• Modern web applications (SPA, React, Angular)
• Microservices architectures

When NOT to Use

• Legacy enterprise systems (SAML is safer)
• When you need SAML-specific features (attribute queries)

Real-World Example

Our national CIAM platform uses OIDC for:

• Citizen authentication via mobile app
• Progressive web app SSO
• Third-party developer integrations

GET /authorize?
  response_type=code
  &client_id=citizen-app
  &redirect_uri=https://app.example.com/callback
  &scope=openid+profile+email
  &state=random-state
  &code_challenge=PKCE-challenge

Pros:

• Built on OAuth2 (familiar)
• JSON-based (lightweight)
• Standardized identity claims
• Mobile-friendly

Cons:

• Newer (less battle-tested than SAML)
• Multiple certification levels (can be confusing)
• Requires careful PKCE implementation

UMA: Fine-Grained Authorization

When to Use

• Resource-level permissions (user-controlled sharing)
• Healthcare data access (patient consent management)
• Financial services (account-level delegation)
• IoT scenarios (device access control)

When NOT to Use

• Simple role-based access (overkill)
• When UMA isn't supported by your stack
• Time-constrained projects (limited expertise)

Real-World Example

We implemented UMA for:

• Citizen-controlled data sharing with third parties
• High-risk transaction approvals
• Delegated access for family members

// UMA Permission Request
POST /uma/permissions
{
  "resource_id": "medical-records-123",
  "scopes": ["read", "share"],
  "requester": "doctor@hospital.com"
}

Pros:

• User-controlled authorization
• Granular resource-level permissions
• Built for consent management

Cons:

• Limited vendor support
• Complex implementation
• Steep learning curve

Decision Tree

Here's my mental model:

                    ┌─────────────────┐
                    │  What are you   │
                    │  protecting?    │
                    └────────┬────────┘
                             │
            ┌────────────────┼────────────────┐
            │                │                │
            ▼                ▼                ▼
     ┌────────────┐  ┌────────────┐  ┌────────────┐
     │Enterprise  │  │  APIs &    │  │  User-     │
     │  Apps      │  │  Services  │  │  Controlled│
     │            │  │            │  │  Resources │
     └─────┬──────┘  └─────┬──────┘  └─────┬──────┘
           │               │               │
           ▼               ▼               ▼
      ┌────────┐     ┌──────────┐    ┌──────────┐
      │ SAML   │     │ OAuth2 + │    │   UMA    │
      │  2.0   │     │   OIDC   │    │          │
      └────────┘     └──────────┘    └──────────┘

My Production Stack

For our national-scale platform, we use all four:

Layer	Protocol	Why
Employee SSO	SAML 2.0	Enterprise app support
Citizen Auth	OIDC	Mobile + web apps
API Gateway	OAuth2	Microservices security
Data Sharing	UMA	Citizen-controlled consent

Implementation Tips

1. Don't implement from scratch — Use battle-tested libraries (Spring Security, Passport.js, Auth0)
2. Always use PKCE — Even for confidential clients (defense in depth)
3. Validate tokens server-side — Never trust client-side validation
4. Log everything — Authentication events are audit gold
5. Test with real tools — Use Postman, curl, and browser dev tools

Final Thoughts

Protocols are tools, not religions. Choose based on:

• Your user population (enterprise vs. consumer)
• Your application architecture (monolith vs. microservices)
• Your compliance requirements
• Your team's expertise

And remember: a well-implemented OAuth2 flow beats a broken OIDC implementation every time.

---

Confused about which protocol fits your use case? Let's discuss.