OAuth2, OIDC, SAML, UMA — When to Use Which (Enterprise Decision Framework)
· 4 min read
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
- Don't implement from scratch — Use battle-tested libraries (Spring Security, Passport.js, Auth0)
- Always use PKCE — Even for confidential clients (defense in depth)
- Validate tokens server-side — Never trust client-side validation
- Log everything — Authentication events are audit gold
- 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.