How it works

How an enterprise customer gets connected, step by step

Follow one enterprise customer, from "we need SSO" to an employee leaving. The customer connects its directory, users and roles flow in automatically, and every sign-in leaves an audit trail. The risky step is the last one: removing someone in the directory doesn't by itself revoke the tokens or API keys the app already issued.

1. Requested. "We need SSO" usually arrives as a line in a security questionnaire: SAML or OpenID Connect sign-in enforced for the customer's domain, SCIM, groups mapped to roles, exportable audit logs, session controls and a SOC 2 report. Many apps offer SSO only on an enterprise plan, the so-called SSO tax (see How the money moves). What can go wrong: sales promises a date before anyone knows which directory the customer runs. Okta and Entra are routine; older on-premises systems can take a quarter each.
2. Connected. The customer proves it owns its email domain, usually with a DNS record, so the app can route everyone at that domain. Then both sides swap settings over SAML or OIDC (URLs, IDs and a signing certificate or client secret), often in a hosted setup screen from WorkOS, Auth0 or Clerk. Test with a real user, then switch on "SSO required" for the domain. What can go wrong: the diagram's Misconfigured exception starts here (below).
3. Provisioned. Just-in-time provisioning creates an account at the user's earliest SSO sign-in with a default role. SCIM lets the directory push users and groups ahead of time and keep them current, and group-to-role mapping turns "Finance-Admins" in Entra into Admin in the app. Roles live per organization, since one person can be an admin in one workspace and a viewer in another. What can go wrong: a SCIM update demotes the only owner, or a user created at sign-in sits outside the groups SCIM manages, so later removals never reach them.
4. Active. Employees sign in through their directory, which now enforces their MFA, and the app records sign-ins, role changes, provisioning events and new API keys for the customer to stream into its security tools. What can go wrong: the customer rotates its signing certificate without telling you, and on Monday morning nobody can sign in; SAML certificates last one to ten years, long enough for everyone to forget them.
5. Deprovisioned. HR marks the employee as gone, the directory disables them and SCIM tells the app to deactivate the account. The diagram's note sits here: tokens outlive the user. SCIM deactivates a record, and ending live sessions, revoking refresh tokens, deleting the user's API keys, removing grants to other apps and handing over what they own are all up to the app. What can go wrong: the Lingering access exception.

Misconfigured comes off the connection step, as wrong claims or a lockout. The usual causes are dull: a wrong callback URL, an expired certificate, attribute names that differ (email against emailAddress) so users get duplicated, missing group claims, or "SSO required" switched on before a break-glass admin exists. The serious kind is a library flaw: in March 2025 GitHub's security team found two bugs in ruby-saml, a widely used SAML library, that let anyone holding one validly signed document sign in as other users. An app that doesn't tie each connection to its own customer can also let one tenant's directory vouch for another tenant's users. A test button, the last working settings kept as a fallback, clear error codes and a maintained SAML library all help.

Lingering access comes off deprovisioning, when someone is gone from the directory and still in the app. It happens when the customer has SSO without SCIM, so removal blocks new sign-ins and leaves existing sessions alone; when the leaver sat outside the groups SCIM manages; or when they also had a password, a personal Google login or long-lived API keys. The standards leave gaps: OpenID Connect's logout messages normally don't revoke long-lived refresh tokens, and a self-contained token can't be recalled before it expires. Clerk's documentation says users removed from an organization rejoin at their next sign-in unless they're also removed in the directory. The fixes are access tokens that last minutes, revoking everything on a SCIM deactivation, transferring what the user owns, and alerting when a deactivated user authenticates. In August 2025 attackers used OAuth tokens stolen from Salesloft's Drift chat integration to pull data from many companies' Salesforce instances, and the tokens worked until Salesloft revoked every connection.

One sign-in, from the login screen to a permission check

One sign-in on the project app, end to end, with where each step can fail:

1. Login screen. The page asks for an email, and the browser may offer a saved passkey. If the domain uses SSO, the app sends the user to that company's directory; otherwise it offers a passkey, a password, an emailed code or social login. Key social logins on the provider's stable user ID, because merging accounts by matching emails is a known way to take one over.
2. Primary factor. A passkey signs a challenge from the app after the user's fingerprint, face or PIN, and the browser lets it sign only for the real site. A password is checked against a salted hash and lists of leaked passwords, with failures throttled. What can go wrong: credential stuffing, bots replaying username and password pairs leaked elsewhere. About a quarter of sign-in attempts on Okta's customer identity service in 2023 looked like stuffing, by Okta's own count.
3. Another factor, if needed. A passkey unlocked with a fingerprint or PIN already counts as two factors under NIST's rules. Otherwise the app asks for a code or a push approval. What can go wrong: app codes and push approvals can be relayed by a phishing kit in real time, push prompts can be spammed until someone taps "approve", and SMS can be redirected by a SIM swap.
4. Risk check. Device, IP reputation, speed and bot signals decide whether to allow, ask for more or block.
5. Session issued. The app sets a session cookie, or the identity provider issues tokens: an ID token saying who signed in, an access token the app's APIs accept, and a refresh token to get new ones, plus which organization the user is acting in. Access tokens should last minutes and refresh tokens should be single-use, so reuse signals theft.
6. Permission check. A request reaches an API, and the gateway checks the token's signature, issuer, audience and expiry. Then the question that matters: may this user take this action on this record in this organization? The answer comes from a role in the token, a permission service or rules in the database, ideally more than one. What can go wrong: the endpoint confirms the user is signed in and never checks that the record belongs to their organization, the flaw at the top of OWASP's list.
7. Step-up and audit. Sensitive actions (changing a payout account, exporting all data, adding an admin) ask for a fresh sign-in or a stronger method, and every decision lands in an audit log: who, what, from where and the result.
8. Logout or timeout. "Logout" means ending the app's session, ending the identity provider's session and revoking tokens. All three are best effort across apps, which is why short token lifetimes matter more than the logout button.

Hard lockouts let anyone who knows an email address lock its owner out, so most products throttle per account and per IP instead, and every unlock path is a recovery path: an account that unlocks by email is only as safe as the inbox. When a takeover is found, revoke every session and refresh token, force a reset, tell the user, and check recent changes: added passkeys, new recovery methods, mail forwarding rules, API keys and app grants.

Cheat sheet: ways to sign in

Passkeys are spreading fast among consumers and slowly at work: 26% of sign-ins used one in 2025 in the FIDO Alliance's index of nine large consumer companies, while Okta's data showed 93% of its customers' employees still signing in with passwords in early 2025. The weak point moves to recovery and fallbacks. If SMS stays enabled, a phishing kit can make the passkey look unavailable and steer the user to a code, which Proofpoint demonstrated in August 2025 without seeing it in real attacks.

Machines, scripts and agents

API keys are long-lived secrets tied to an account or project: simple, coarse and easy to leak. GitGuardian, which sells secret scanning, counted about 28.65 million new secrets exposed on public GitHub in 2025. Service accounts and OAuth client credentials give a program its own identity and short-lived scoped tokens. Device-flow login ("go to this page and type this code") lets command-line tools get a session; in early 2025 Microsoft reported a Russia-linked group phishing people into typing codes the attackers had generated. Personal access tokens let users script against the API and are the tokens most often left behind at offboarding.

AI agents are the newest machine identity, acting for a person. OAuth's 2020 token-exchange standard separates impersonation (the agent looks exactly like the user) from delegation (the token records "this agent acting for this user"), and MCP, the protocol agents use to call tools, builds its authorization on OAuth. Vendors selling tools for this count from about 17 to over 100 machine identities per person, which mostly shows their definitions differ.