A fast-growing company hits 500 engineers. IT is drowning in Jira tickets: "reset my password," "I need access to Datadog," "why can't the new contractor see the staging AWS account?" The VP of Engineering wants one login for everything. The security team wants audit trails. The platform team wants to stop hand-configuring Okta.
Every identity protocol and system in this post exists because that company's pain is real, and each concept solves a specific piece of it. Let's walk through what happens when you actually automate enterprise identity — from the first SSO rollout to full identity-as-code.
Phase 1: "Everyone Is Drowning in Passwords" — SSO
The first ask is always the same: "Can people just log in once?"
SSO (Single Sign-On) is a UX pattern — not a protocol. The user enters credentials once at a central Identity Provider (IdP) and gets access to Slack, Jira, GitHub, Datadog, and AWS without logging in again. That's the outcome. The question is how.
Phase 2: "Wire Up the Enterprise Apps" — SAML
The platform team opens Salesforce, Workday, and Jira's admin consoles. Every one of them has the same integration option: SAML 2.0.
SAML (Security Assertion Markup Language) is an enterprise authentication and federation protocol based on XML. The IdP (Okta, in this case) signs XML "assertions" — digitally signed documents that say "this user is jane@acme.com, she authenticated at 2:14 PM, and she belongs to the Engineering group." The Service Provider (Salesforce, Jira) trusts that assertion and lets her in.
SAML dominates traditional corporate SSO because enterprise SaaS vendors have supported it for 15+ years. If the vendor's admin console has an "SSO" tab, it's almost certainly SAML.
What it answers: "Who is this user?" — authentication and identity federation.
Phase 3: "Let the Scheduling Tool Read My Calendar" — OAuth
An engineer wants to connect a meeting-scheduling app to their Google Calendar. The app doesn't need to know who the engineer is — it just needs permission to read calendar events on their behalf.
OAuth 2.0 (Open Authorization) is an authorization framework — not an authentication protocol. It does not verify who you are; it answers what can this app do on my behalf? OAuth issues access tokens that grant limited, scoped, delegated access to specific resources — without exposing the user's password.
This is the pattern behind every "Allow this app to access your Google Calendar?" consent screen.
What it answers: "What can this app do on my behalf?" — delegated access, not identity.
Phase 4: "Build a Modern Login for Our Customer Portal" — OIDC
Now the product team wants a customer-facing portal with "Log in with Google" and "Log in with Apple." SAML is too heavyweight for mobile and SPAs. OAuth alone doesn't tell you who logged in. They need both authentication and authorization in one modern, lightweight flow.
OIDC (OpenID Connect) is an authentication layer built on top of OAuth 2.0. It adds an ID token — a JSON Web Token (JWT) containing the user's identity (email, name, profile picture) — alongside the OAuth access token. One flow, two tokens: the ID token proves who they are, the access token proves what they can touch.
"Log in with Google" is an OIDC flow. So is "Log in with Apple," "Log in with GitHub," and every modern consumer SSO integration.
What it answers: "Who is this user?" + basic profile + "What can they access?" — authentication and authorization.
How the Protocols Compose
At this point the company is running all three, and they aren't competing — they're layered:
- SSO is the goal — one login for all tools.
- SAML delivers enterprise app login — Salesforce, Workday, Jira.
- OIDC delivers modern app login — the customer portal, mobile apps.
- OAuth 2.0 runs underneath OIDC and handles API delegation when an app needs to call APIs on the user's behalf after login.
| SAML 2.0 | OAuth 2.0 | OpenID Connect (OIDC) | |
|---|---|---|---|
| Primary function | Authentication / Federation | Authorization (Access) | Authentication + Authorization |
| Answers | "Who is this user?" | "What can this app do on my behalf?" | "Who is this user?" + basic profile |
| Data format | Verbose XML | JSON / Bearer Token | JSON Web Tokens (JWT) |
| Best use case | Enterprise corporate apps | Delegated API access | Modern web, mobile, & consumer login |
| Typical tools | Okta, ADFS, PingFederate | Google/GitHub OAuth apps | Okta OIDC apps, Auth0 |
Phase 5: "Where Does Everyone's Account Actually Live?" — IdP and Identity Store
SSO is working. But then: "We acquired a company. Their engineers are in Active Directory. Ours are in Okta. How do we merge?"
This is where the IdP and Identity Store distinction matters:
- IdP (Identity Provider): The system that authenticates users and issues tokens — Okta, Azure AD, PingFederate. It answers: "Who authenticated this person?"
- Identity Store: The database of record for who exists — Active Directory, Okta Universal Directory, LDAP. It answers: "Where does identity data actually live?"
Okta can be both the IdP and the identity store. But in many enterprises, Okta authenticates users while Active Directory remains the source of truth for employee records. Understanding which system is authoritative for identity data is critical when you start automating provisioning.
Phase 6: "New Hires Wait 3 Days for Access" — SCIM
The company is hiring 20 engineers a month. HR creates the employee in Workday. IT manually creates accounts in Okta, Jira, GitHub, Datadog, and AWS. It takes three days and someone always misses a system.
SCIM (System for Cross-domain Identity Management) is a protocol for automatically syncing user and group data between systems. When HR creates a user in Workday, SCIM pushes that identity downstream: Okta account created, group memberships assigned, app access provisioned — all within minutes, no tickets.
When someone leaves? SCIM deprovisioning removes their accounts everywhere. No orphaned credentials.
What it answers: "How do accounts get created, updated, and removed downstream?" — automated lifecycle management.
Phase 7: "Not Everyone Should See Everything" — RBAC
With 500 people accessing 40 apps, the security team asks: "Why does every engineer have admin access to the production AWS account?"
RBAC (Role-Based Access Control) ties permissions to roles, not individuals. An engineer gets the platform-eng role, which grants read-only access to production, write access to staging, and admin access to dev. A new hire gets the role; a departing engineer loses it. Permissions flow from the role, not from individual grants scattered across 40 apps.
What it answers: "What is this role allowed to do?" — access governance at scale.
The Full Stack in One View
Every concept is a layer, and they compose:
| SAML | OAuth 2.0 | OIDC | SSO | IdP | Identity Store | RBAC | SCIM | |
|---|---|---|---|---|---|---|---|---|
| What it is | XML auth/identity protocol | Delegated authorization protocol | Auth layer on top of OAuth 2.0 | UX pattern: one login, many apps | System that authenticates users and issues tokens | Database of record for identities | Access-control model: permissions tied to roles | Protocol for syncing user & group data between systems |
| Answers | "Who is this user?" | "What can this app do on my behalf?" | "Who is this user?" + basic profile | "Is the user already logged in?" | "Who authenticates users for my apps?" | "Where does identity data actually live?" | "What is this role allowed to do?" | "How do accounts get created/updated/removed downstream?" |
| Typical tool | Okta, ADFS, PingFederate | Google/GitHub OAuth apps | Okta OIDC apps, Auth0 | Okta dashboard, Azure AD portal | Okta, Azure AD, Google Workspace | Active Directory, Okta Universal Directory, LDAP | Okta groups + app permissions, AWS IAM roles | Okta SCIM connectors, Provisioning Agents |
Phase 8: "Stop Clicking Through Admin Consoles" — Identity as Code
The company now has 2,000 engineers, 120 SaaS apps, 30 AWS accounts, and 4 Okta admins. Every access change is a manual console click. An audit reveals 47 orphaned service accounts, 12 users with permissions they shouldn't have, and zero rollback capability.
The platform team's mandate: treat identity like infrastructure — define it in code, review it in PRs, deploy it through pipelines.
| Admin-Console IAM | IAM-as-Code | |
|---|---|---|
| Change process | Click through Okta/AWS console | terraform apply from a reviewed PR |
| Audit trail | Console logs, screenshots | Git history — who approved what, when |
| Rollback | Manual, error-prone | git revert + terraform apply |
| Drift detection | Hope and periodic manual review | terraform plan shows exact drift |
| Access reviews | Spreadsheet + calendar reminder | GitOps: access defined in code, PR-based review cycles |
| Scale | One admin, dozens of apps | One pipeline, hundreds of apps and policies |
What this looks like in practice:
- Okta app assignments and group rules declared in Terraform (via the okta provider)
- AWS IAM policies, roles, and permission boundaries managed as .tf files
- SCIM provisioning configured as code — new hire onboarding triggers downstream account creation automatically
- Access reviews run as PR-based workflows: remove an engineer from a group in code, the pipeline deprovisions everywhere
Phase 9: "Our CI/CD Pipeline Has a Static AWS Key" — Workload Identity
The security team finds a long-lived AWS access key hardcoded in a GitHub Actions workflow. It has AdministratorAccess. It was created two years ago. Nobody knows who owns it.
Workload identity is identity for non-human principals — services, CI/CD pipelines, and AI agents. The solution: OIDC-based workload identity federation. GitHub Actions presents an OIDC token to AWS, which exchanges it for short-lived STS credentials scoped to exactly the permissions that pipeline needs. No static secrets. No keys to rotate. No keys to leak.
| Concept | What It Is | Why It Matters |
|---|---|---|
| AWS IAM | AWS's native identity/permission system — users, roles, policies | The thing you push policy changes into via Terraform |
| AWS IAM Identity Center (formerly AWS SSO) | AWS's broker that federates an external IdP (Okta) into AWS account access via SAML/OIDC | Classic pattern: Okta (IdP) → Identity Center → temporary AWS role credentials |
| IAM Roles vs Users | Roles are assumed temporarily (via federation/STS); users have persistent credentials | Platform-as-code work favors roles — no static creds to rotate or leak |
| Workload / machine identity | Identity for services, CI/CD pipelines, or AI agents — not humans | Non-human principals are the frontier problem in IAM right now |
| Terraform + IAM | Declaring IAM policies, Okta apps, and group assignments as .tf code instead of console clicks |
This is the actual deliverable of "identity as code" |
Decision Framework: Picking the Right Combination
| Building... | Use |
|---|---|
| Consumer-facing app (web/mobile login) | OIDC (+ OAuth 2.0 for API access) |
| Enterprise B2B tool with corporate SSO | SAML 2.0 for authentication, SCIM for provisioning |
| API-to-API delegation (no user present) | OAuth 2.0 client credentials flow |
| Internal platform managing identity at scale | OIDC + SCIM + RBAC + Terraform, all as code |
| Non-human / workload identity (CI/CD, AI agents) | OIDC-based workload identity federation — no static secrets |
Key Takeaways
- SSO is an outcome, not a protocol — SAML and OIDC are the protocols that deliver it.
- OAuth ≠ authentication — it handles authorization (delegated access). OIDC adds the identity layer on top.
- SAML dominates enterprise, OIDC dominates consumer/mobile — know when to use which.
- SCIM eliminates the 3-day onboarding wait — automated provisioning and deprovisioning across all downstream systems.
- RBAC governs access at scale — permissions tied to roles, not individuals, across hundreds of apps.
- Identity as code is the endgame — Terraform + GitOps for IAM policies, Okta apps, and access reviews eliminates console drift and scales to thousands of engineers.
- Workload identity is the frontier — non-human principals (services, pipelines, AI agents) need short-lived tokens via OIDC federation, not static secrets.
References: ISDecisions, Dev.to — Neelendra Tomar, Nikki Siapno — LinkedIn, Okta, Auth0, Microsoft Learn, OneLogin, Pomerium, Fortinet, Oloid
No comments:
Post a Comment