You click "Sign in with Google" on GitHub. Seconds later, you are in. No new account. No new password.

That felt simple. The system behind it is not.

This article breaks down the four protocols that power modern identity management: SSO, SAML, OIDC, and SCIM. You will understand what each one does, where they differ, and how they work together in real companies like Netflix and Airbnb.

The Problem These Protocols Solve

Before SSO, every app had its own login database. A new employee joining a company needed separate accounts in Gmail, Slack, Jira, Salesforce, and every other tool. IT teams created each account by hand. When someone left, accounts often lingered for weeks, open to misuse.

Three problems emerged:

• Users carried dozens of passwords, and reused them
• IT spent hours on account creation and resets
• Every separate login system was a separate attack surface

SSO solves this by centralizing authentication. You log in once to a trusted Identity Provider (IDP) and every other app trusts that login. One credential. One place to enforce MFA. One place to revoke access.

But SSO is not a single technology. It is a goal. SAML, OIDC, and SCIM are the tools that achieve it.

The Three Main Players in Any SSO Flow

Before going into protocols, know these three roles:

User: The person trying to access a service.

Identity Provider (IDP): The system that verifies the user's identity. Examples: Okta, Azure AD, Google Workspace.

Service Provider (SP): The application the user wants to access. Examples: Salesforce, GitHub, Slack.

The IDP and SP are separate systems. They trust each other through a formal agreement called federation. Federation lets your company's IDP issue a kind of digital passport, and every connected app checks that passport at the door.

SAML: The Enterprise Veteran

SAML stands for Security Assertion Markup Language. It is an open standard that has powered enterprise SSO since 2002.

Here is the step-by-step SAML flow:

1. You try to access Salesforce (the Service Provider)
2. Salesforce redirects you to your IDP (say, Okta)
3. Okta asks for your credentials and verifies them, including MFA
4. Okta generates a SAML Assertion, an XML document containing your identity, roles, and group memberships
5. Okta sends that assertion back to Salesforce
6. Salesforce verifies the IDP's digital signature on the assertion and grants access

The assertion is the key artifact. It carries signed proof of who you are and what roles you hold. Salesforce does not store your password. It trusts Okta's signature.

Where SAML excels:

• Legacy enterprise apps (Salesforce, Workday, ServiceNow)
• Organizations with strict compliance requirements (healthcare, government)
• Web browser-based SSO flows

Where SAML struggles:

• Mobile apps, which do not handle XML-based browser redirects well
• APIs and microservices that prefer JSON
• Modern single-page applications

Real example: A hospital network uses SAML to give doctors access to patient record systems, billing tools, and scheduling software with one login. Auditors get a single log of every access event. SAML's verbose XML is worth the overhead when the data is sensitive and regulated.

OIDC: The Modern API-Friendly Option

OpenID Connect, or OIDC, is built on top of OAuth 2.0. OAuth handles authorization (what an app is allowed to do on your behalf). OIDC adds the missing authentication layer (who you actually are).

When you click "Sign in with Google" on GitHub, you are using OIDC.

Here is the flow:

1. You click "Sign in with Google" on GitHub
2. GitHub redirects you to Google's authorization server
3. Google asks for your credentials
4. Google sends back two tokens: an Access Token and an ID Token
5. The ID Token is a JWT (JSON Web Token) signed by Google, containing your identity
6. GitHub reads the JWT, verifies Google's signature, and logs you in

The JWT looks like this (decoded):

{
  "sub": "1234567890",
  "name": "Jane Doe",
  "email": "jane@example.com",
  "iss": "https://accounts.google.com",
  "exp": 1716560000
}

This is lightweight, JSON-based, and works seamlessly in mobile apps, SPAs, and API calls.

SAML vs OIDC at a glance:

Real example: Spotify's mobile app uses OIDC when you log in with Facebook. The app receives a JWT, verifies it, and creates your session without ever touching Facebook's password system.

SCIM: The Account Lifecycle Manager

SAML and OIDC handle authentication. They answer: who is this user?

SCIM (System for Cross-domain Identity Management) answers a different question: does this user's account exist in the first place, and does it have the right attributes?

SCIM is a REST API specification. If your app implements SCIM endpoints, an IDP like Okta or Azure AD can automatically:

• Create accounts when someone joins
• Update attributes when someone changes teams
• Deactivate accounts when someone leaves

Here is what SCIM looks like in practice:

Create a new user (IDP calls your app):

POST /scim/v2/Users
{
  "userName": "jane.doe@company.com",
  "name": { "givenName": "Jane", "familyName": "Doe" },
  "department": "Engineering",
  "active": true
}

Deactivate a user on departure:

PATCH /scim/v2/Users/12345
{
  "Operations": [{ "op": "replace", "path": "active", "value": false }]
}

When Jane joins the company, her IDP account triggers SCIM calls to Slack, Zoom, GitHub, and Jira. Her accounts appear before her first day. When Jane leaves, one deactivation in the IDP removes access everywhere within minutes.

Real example: Netflix built an internal "People Service" that ingests identity data from Workday and Azure AD, then distributes it to hundreds of internal tools via SCIM and internal APIs. Without this, onboarding a new engineer would require tickets to a dozen different teams.

How the Three Protocols Work Together

These are not competing standards. Each solves a different layer of the same problem.

HR System
    |
    | (triggers onboarding event)
    v
Identity Provider (Okta / Azure AD)
    |
    |-- SCIM --> Creates accounts in Slack, GitHub, Zoom, Salesforce
    |
    |-- SAML --> Authenticates users in legacy enterprise apps
    |
    |-- OIDC --> Authenticates users in modern apps and APIs

A concrete scenario:

1. A new engineer joins. HR updates their record.
2. Azure AD receives the event and uses SCIM to create accounts in GitHub, Slack, and Jira with the correct team permissions overnight.
3. The next morning, she logs into Azure AD once.
4. Azure AD uses OIDC to authenticate her into the internal developer portal.
5. Azure AD uses SAML to authenticate her into the legacy finance system.
6. She accesses everything without logging in again.
7. Six months later, she leaves. Azure AD deactivates her account. SCIM removes her access from every connected app within minutes. SAML and OIDC stop issuing tokens for her identity.

The Pros and Cons

SSO (the goal):

Pros:

• One set of credentials for all apps
• Centralized MFA enforcement
• Single audit log for access events
• Faster onboarding and offboarding

Cons:

• If the IDP goes down, users lose access to everything
• Requires careful configuration between IDP and each service provider
• Single point of compromise if the IDP is breached without strong MFA

SAML:

Pros:

• Mature, battle-tested in enterprises
• Carries rich attributes (roles, groups, departments)
• Strong support in legacy enterprise apps

Cons:

• XML is verbose and complex to debug
• Poor fit for mobile apps and APIs
• Implementation errors (like signature validation mistakes) are a common source of vulnerabilities

OIDC:

Pros:

• Lightweight JSON tokens
• Works everywhere: web, mobile, APIs
• Built on OAuth 2.0, which developers already know

Cons:

• JWT misconfiguration (like skipping signature validation) creates security holes
• Token expiry and refresh logic requires careful handling

SCIM:

Pros:

• Eliminates manual account management
• Reduces orphaned accounts (a major security risk)
• Standardized, so IDPs support it out of the box

Cons:

• Not every app supports SCIM endpoints
• Centralizing SCIM in a sync service adds architectural complexity
• Debugging sync failures across many apps is non-trivial

Where This Fits in the Bigger Picture: IAM

SSO, SAML, OIDC, and SCIM are components of a broader discipline called Identity and Access Management (IAM).

IAM covers:

• Authentication (AuthN): Proving who you are. SAML, OIDC, MFA.
• Authorization (AuthZ): Controlling what you can do. RBAC, ABAC, policy engines like OPA.
• Provisioning: Managing account lifecycles. SCIM.
• Federation: Trust between organizations. SAML, OIDC across org boundaries.

A practical distinction worth knowing: AWS IAM is Amazon's system for controlling access to AWS resources (S3, EC2, Lambda). It is not a general enterprise IDP. Most companies use Okta or Azure AD as their central IDP and connect to AWS through federation and role mappings.

When a developer logs into AWS through Okta SSO, Okta authenticates them (via SAML or OIDC) and passes their identity to AWS IAM, which then decides what resources they can access.

A Real Security Consideration: The SSO Risk Trade-Off

SSO reduces password sprawl and improves user experience. But it concentrates risk.

If an attacker compromises an employee's IDP credentials and MFA, they gain access to every federated application at once. This is why:

• MFA on the IDP is not optional, it is the primary defense layer
• Conditional access policies (blocking logins from unrecognized devices or locations) are critical
• Session timeouts should be enforced at the IDP level
• Privileged accounts should use hardware security keys (FIDO2), not TOTP codes

The 2023 MGM Resorts breach reportedly started with social engineering an IT help desk into resetting an Okta account. The attacker then moved laterally across MGM's systems using the SSO trust relationships. SSO amplified the blast radius of a single credential compromise.

The lesson: SSO is more secure than password sprawl when configured correctly. The IDP is the crown jewel. Protect it accordingly.

Summary

• SAML handles authentication for enterprise web apps using XML assertions. Mature, verbose, and essential for legacy systems.
• OIDC handles authentication for modern apps and APIs using lightweight JSON tokens. Built on OAuth 2.0.
• SCIM handles account lifecycle management. It creates, updates, and removes user accounts automatically across all your apps.
• SSO is the goal. SAML and OIDC are the protocols that deliver it. SCIM keeps the underlying accounts in sync.
• IAM is the full framework. SSO is one piece of it.

If you are building a product today, start with OIDC for authentication and implement SCIM endpoints if you want enterprise customers (they will ask for it). If you are connecting to legacy enterprise systems, SAML support is non-negotiable.

Found this useful? Share it with your team. If you want a deeper breakdown of OAuth 2.0 flows, JWT security, or RBAC versus ABAC authorization models, drop a comment below.