Federation, Delegation, and Automation: The IAM Protocols That Actually Run Your Stack

Identity & Access · 8 min read

Why protocols exist?

Every time you click "Sign in with Google," five different protocols fire off in under a second. Most of the time, you never think about it. Until you're the one building it.

In Part 1 we covered the IAM framework — what identity and access mean, how MFA works, and how authorization models like RBAC and ABAC divide up permissions. But we left one question unanswered: how do thousands of apps actually coordinate all of this behind the scenes?

That's what protocols are for. This part covers four of them — SCIM, SAML, OAuth 2.0, and OpenID Connect — each solving a distinct piece of the puzzle the others can't.

SCIM — Automated provisioning, the unsung hero

When a company hires 200 people on Monday, who creates their Gmail, Slack, Jira, and 30 other apps? And when someone quits, who remembers to delete all of them? If the answer is "IT tickets," you have a problem. People get missed. Accounts linger for months after someone leaves, which is a security nightmare. Access creeps. Reviews slip.

SCIM - System for Cross-domain Identity Management

When a company hires 200 people on Monday, who creates their Gmail, Slack, Jira, and 30 other apps? And when someone quits, who remembers to delete all of them? If the answer is "IT tickets," you have a problem. People get missed. Accounts linger for months after someone leaves, which is a security nightmare. Access creeps. Reviews slip.

SCIM is the boring, beautiful protocol that fixes this. It's a REST API specification for creating, updating, and deleting user accounts across systems automatically. It defines a standard schema for users and groups, and a standard set of REST endpoints exposing POST, GET, PATCH, and DELETE operations on them.

How SCIM actually works?

1. An event happens in a source of truth. Usually the HR system: someone joined, someone was promoted, someone left.

2. The HR system fires that event at the identity provider (Okta, Azure AD) via SCIM.

3. The IdP creates or updates the user in its identity repository.

4. The IdP pushes the change via SCIM REST calls to every connected downstream app --- Gmail, Slack, Jira, Zoom, GitHub --- that has a SCIM endpoint.

5. All accounts get created, updated, or deactivated automatically. No tickets.

SCIM Centralization

A subtle point that only hits you once you've built this yourself. If every internal app implemented SCIM directly, you'd have a massive problem: every codebase maintains its own SCIM compliance. Every spec change triggers redundant work across dozens of services. Logs are scattered. Behavior is inconsistent.

That's where a centralized SCIM service earns its keep. Instead of every internal system listening to SCIM directly, companies build a central service between the IdP and the apps.

A centralized SCIM service plays two roles:

• Passive role --- exposes SCIM-compliant endpoints (/Users, /Groups) so the IdP can push user and group updates using the standard spec.

• Active role --- becomes the source of truth for internal systems. Once user data is stored there, it actively syncs out to other apps using internal APIs rather than SCIM.

SCIM compliance lives in one place. Spec changes happen once. Logs are centralized. Internal apps get a simpler, stable interface and don't each have to speak REST-compliant SCIM.

"MFA proves you are still you. SCIM makes sure you exist --- or don't --- in the right places. The protocols come next."

SAML - The Enterprise Gatekeeper

SAML is what happens when a big serious company with compliance officers decides to do single sign-on. It's verbose, it's XML, and it's been running enterprise logins since 2005.

Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between two parties: an Identity Provider (IdP) and a Service Provider (SP). It was designed to solve one specific problem --- single sign-on across different organizations --- without exposing passwords.

The three actors

• User --- the human who wants to use a service.

• Identity Provider (IdP) --- knows who you are and verifies it. Examples: Google Workspace, Okta, Microsoft Entra ID, ADFS.

• Service Provider (SP) --- the application you're trying to use. Examples: Salesforce, Microsoft 365, Workday, Jira.

The SAML Assertion

At the heart of SAML is the assertion --- an XML document signed by the IdP that says, essentially: "yes, this is a real user, here's their name, email, and role, and I'm vouching for them at this exact time."

The assertion contains:

• User info --- name, email

• Authorization levels --- roles, permissions

• Timestamps --- when issued, when it expires

• A digital signature from the IdP so the SP can verify authenticity

SAML in practice

SCENARIO / SAML WORKED EXAMPLE

Priya is a sales rep at Acme Corp. Acme uses Okta as their identity provider. Priya opens her laptop in the morning, types acme.my.salesforce.com in her browser, and just... ends up logged in. Here's every single thing that happened behind the scenes:

Notice what Priya never did: create a Salesforce password. Notice what Salesforce never saw: Priya's password or her YubiKey touch. The only thing it got was a signed XML statement from a system it already trusts. That's the whole magic.

OAUTH 2.0 - Delegated Authorization

OAuth 2.0 solves a completely different problem. Imagine a scheduling app wants to read your Google Calendar so it can suggest meeting times. The bad solution: give the app your Google password. You've now handed over permission to do anything --- read all your email, delete photos, change your account recovery, lock you out.

OAuth's core idea is delegated, limited authorization. Instead of sharing a password, you get a token. The token says: "this app can read this user's calendar, for the next hour, and nothing else."

The four actors

• Resource Owner --- you, the user who owns the data.

• Client --- the third-party app that wants access (e.g., the scheduling app).

• Authorization Server --- issues the token after you consent (e.g., Google's OAuth endpoints).

• Resource Server --- holds the data and accepts the token (e.g., Google Calendar API).

The access token --- what's actually passed around

The access token is the core of OAuth. It's issued by the authorization server, handed to the client, and presented to the resource server when the client wants to do something. Key properties:

• It is not your password.

• It is scoped --- it lists exactly which permissions were granted.

• It is short-lived --- expires, often in minutes or hours.

• It can be revoked at any time by the user.

The same pattern runs behind "Sign in with Google," "Log in with Facebook," "Connect your Dropbox" --- any time a third-party app gets scoped, revocable access to your data without ever seeing your password.

OAUTH 2.0 WORKED EXAMPLE

Priya wants to order prints of her vacation photos from PrintMyPics, a third-party photo-printing service. Her photos live in Google Photos. PrintMyPics needs read access --- but has no business knowing her Google password. Here's the OAuth 2.0 flow step by step:

Two weeks later, Priya visits her Google account settings, finds PrintMyPics in "Third-party apps with account access," and clicks "Remove access." The token dies. Future API calls return 401 Unauthorized. She never changed her password. She never exposed her Google account. That's the whole point.

OpenID Connect PROTOCOL

Here's the historical mess: OAuth 2.0 was never designed to tell you who a user is. It was only ever designed to say what an app is allowed to do. But developers kept abusing OAuth for login anyway --- basically asking "hey Google, give me a token for this user's profile, and if I can get that token, I'll assume they're logged in."

This kind of worked. It also kind of didn't. There was no standard way to describe who the user was, and every implementation handled it slightly differently. So in 2014, a new standard emerged: OpenID Connect (OIDC).

What's actually different?

Two things change when you add OIDC on top of OAuth:

• You request the openid scope --- tells the auth server "also give me identity info, not just permission tokens."

• You get back an ID token alongside the access token. The ID token is a signed JWT (JSON Web Token) containing claims: user ID, name, email, issued-at, expires-at, issuer.

The access token is still for making API calls. The ID token is purely for proving identity --- it's cryptographically signed, your backend can verify it locally, and you don't have to trust the access token to figure out who's logged in.

OIDC WORKED EXAMPLE

Priya wants to use Notion for her personal notes. Notion's login page shows three buttons: Email, Google, Apple. She clicks "Continue with Google." Here's what happens:

The three-way comparison

Now that all three protocols are on the table, here's the side-by-side. This comparison gets muddled constantly --- people call SAML and OAuth "competitors" when they're not, or confuse OAuth and OIDC when one is built on the other. The honest answer: each was built for a different problem, and they all survived because they each win in their own territory.

Summary

After all this, there's one sentence that captures the whole thing: SAML and OIDC both answer "who is this user?" --- just in different eras and formats. OAuth answers a completely different question: "what is this app allowed to do?"

Rule of thumb: enterprise laptop + legacy apps → SAML. Modern app + external login button → OIDC. Third-party app needs to touch your data → OAuth.

The whole picture in one story, stitched together from everything above. You are a hardware engineer on your first day. Follow the acronyms.

1. SCIM --- HR marks you "started." The event fires via SCIM to Okta, which creates your identity record. Okta fans out via SCIM to every connected app --- AWS, Slack, GitHub, Jira, email --- creating your accounts automatically.

2. MFA --- you boot your laptop. Okta's policy requires password and fingerprint. Two factors, different categories. Authenticated.

3. SAML --- through federation, Okta vouches for you via a signed SAML assertion to AWS and Slack. You log in once. No second password anywhere.

4. IAM + RBAC --- inside AWS, you can edit dev-environment settings because your role says so. You cannot delete production; RBAC blocks it.

5. IAM + ABAC --- you try logging in from a coffee shop. ABAC policy blocks you: non-corporate IP, access denied. Come back when you're on the VPN.

6. OAuth 2.0 --- a scheduling app asks for your Google Calendar. You grant it a scoped, short-lived token. The app never sees your password. You revoke it two weeks later with one click.

7. SCIM --- two years later, you leave. HR flips one bit. SCIM propagates the deactivation to all 50 apps instantly. No lingering access.

All mechanisms worked together. You, as the engineer, barely noticed any of them. That's the goal.

Quick Reference

• SCIM — automated user provisioning and de-provisioning across systems.
• SAML — XML-based SSO protocol for enterprise apps.
• OAuth 2.0 — delegated authorization via short-lived tokens.
• OIDC — OAuth 2.0 plus identity. What "Sign in with Google" uses.

Build something boring and bulletproof. Your future self — and your security team — will thank you.