What is workforce identity? A guide to employee access

Workforce identity is how an organization manages accounts and access for employees, contractors, and partners. It covers how people sign in, which apps and permissions they get, how access changes over time, and the records needed to verify those changes.

Workforce identity connects a source of truth with the systems that grant and record access.

What workforce identity covers

These six parts provide a useful way to review how your organization manages access.

Some vendors package several of these layers into one platform. Okta, for example, describes Workforce Identity as combining single sign-on, adaptive MFA, lifecycle management, and identity governance. Even in a bundle, each layer has its own settings and needs its own review.

Following one employee through joining, moving, and leaving

Take Maya, a hypothetical new hire at a 150-person company.

Access changes as a person joins, changes roles, and leaves.

When Maya joins, HR creates her record and she is added to the directory, which is the source of truth for the user and group lists that downstream systems read. Provisioning then creates her account in each connected app and sets its attributes. One common way to do this is SCIM, which tells each app about account creation, attribute updates, and deletion. Okta Lifecycle Management, for instance, can automate this step by syncing with an HR system.

When Maya changes teams, her group membership changes in the directory. Apps that map roles from directory groups can update her permissions once they receive the changed membership. WorkOS documents this pattern in its directory group role assignment guide. Apps where someone granted her access by hand do not, because that grant is not tied to the directory. Those apps drift away from the source of truth, and Maya can end up with the access of both teams.

When Maya leaves, her directory account is deactivated and the connected apps have to be updated. How that update arrives depends on the IdP and the app. In SCIM, one option is a DELETE request against /Users/{id}, which removes her user resource from the app. Even after that, her browser sessions, refresh tokens, and any API keys she created can outlive deprovisioning. Whether they end depends on how each app handles sessions and credentials.

Why a successful sign-in is not the same as access

A successful sign-in establishes who the person is. Whether they have an account in the app, and what they can do there, are separate questions.

With OIDC, for example, an application verifies the user's identity based on authentication performed by an authorization server. OIDC adds authentication as an extension to OAuth 2.0's authorization process, and the app receives the result as an ID token.

Whether sign-in also creates an account depends on the setup. With just-in-time (JIT) provisioning, the application creates an account on the user's first successful sign-in. Authentication alone does not create that record: the standalone WorkOS SSO API leaves user database management to your application.

Ending access is a separate job again. An earlier successful login does not tell the app whether that person has since left the company, so the app needs to receive access changes and enforce them on existing sessions. SCIM can cover the first part: it is a protocol for creating, modifying, retrieving, and discovering User and Group resources. Ending a session the user already has open is outside that scope, so if sessions should end at offboarding, something inside each app has to enforce it. For where this tends to go wrong, see our write-up on how apps break the SCIM deprovisioning promise.

How workforce identity differs from customer identity

The distinction is whose access you manage. Workforce identity covers the people working for your organization. Customer identity and access management (CIAM) covers the people using your products. A B2B customer's employees can appear in both: their employer manages their work identity, and your app manages their access to your product.

Microsoft Entra, for example, builds this split into its tenant model. A workforce tenant configuration is for your employees, internal business apps, and other organizational resources and represents a single organization. CIAM runs in a separate external tenant. For a fuller comparison, including what it means for a B2B product, read CIAM vs. IAM.

Five questions to answer before you buy anything

1. What is our source of truth, and do the other systems agree with it? Downstream systems read user and group lists from the directory, so if the HRIS and the directory disagree, every app that relies on the directory inherits the error.
2. Which apps are provisioned automatically, and which depend on someone granting access by hand? Write both lists down. The manual list is where offboarding is easiest to miss.
3. When someone changes teams, what changes without anyone stepping in? Check that apps receive group-membership changes and apply the corresponding roles. Access granted by hand does not, and it drifts from the source of truth.
4. How long does access last after we disable an account? Check session and token lifetimes in each app, and whether API keys the person created still work, because deprovisioning does not necessarily end them.
5. Can we show an auditor who had access to what last quarter? Test whether your records can reconstruct that access. A list of current permissions will not answer a question about the past.

Where B2B SaaS products fit

If you sell software to companies, your app is one of the apps in your customers' workforce identity setup. Your app can connect to their identity provider over SAML or OIDC and receive directory updates to keep its user lists in sync. WorkOS SSO and Directory Sync are developer products for building those connections into your app. They connect your app to your customers' identity systems; they are not an identity provider for your own employees. If you want a full authentication layer instead of a standalone API, you can integrate SSO through AuthKit.