Every company runs two identity systems whether it planned to or not. One signs employees in to the tools they work with. The other signs customers in to the product the company sells. They look alike on a whiteboard and behave very differently in production.

What each one is

Workforce identity covers the people who work for you: employees, contractors and, increasingly, the service accounts and AI agents that act for them. The organisation creates these accounts, decides what they may reach and removes them when the person leaves.

Customer identity, usually called CIAM (customer identity and access management), covers the people who use what you sell. They create their own accounts, on their own devices, at a time of their choosing. If your customers are businesses, each customer also has its own members, admins and often its own identity provider.

The underlying mechanics are the same: an account, a credential, a session, a token. What differs is who is in charge of the account and what happens when things go wrong.

How they differ

Who owns the account

A workforce account belongs to the employer. An administrator can reset it, suspend it and read its audit trail without asking the person. A customer account belongs to the customer. They choose whether to sign up, they can ask you to delete it, and privacy law in many places gives them rights over the data attached to it.

Scale and shape

Workforce directories are bounded by headcount. They are small, dense and structured: every person sits in several groups, and most access decisions are made by group.

Customer directories are bounded by your market. They are large, sparse and bursty: most accounts have no group at all, sign-ups arrive in spikes after a launch, and a large share of accounts go quiet after the first week.

Lifecycle

This is the largest difference in practice.

  • Workforce: joiner, mover, leaver. Accounts are created by a process, usually from an HR system or an upstream directory, often over SCIM 2.0. A change of team changes group membership. Leaving removes everything, ideally at once.
  • Customer: sign up, verify, return, recover, delete. Accounts are created by the user. The hard parts are verifying an email address, merging duplicates, recovering access without handing the account to an attacker, and honouring deletion requests.

An employee who loses a device calls a help desk that can check who they are. A customer has no help desk that knows them, so the recovery flow is the weakest door into the account. We cover that in account recovery without account takeover.

Sign-in methods

Workforce sign-in is mostly federation. People authenticate once at the company identity provider and reach other applications over SAML 2.0 or OpenID Connect. Policy can be strict because the employer can require it: a second factor for everyone, a managed device for sensitive applications.

Customer sign-in has to balance security against the fact that every extra field loses sign-ups. Typical methods are passkeys, passwords, email codes and social sign-in. If you sell to businesses, larger customers will ask to sign in with their own provider, which means your product becomes the service provider in someone else's federation. The difference between the two protocols is covered in SAML vs OIDC.

Branding and experience

Nobody minds if the employee sign-in page looks like the vendor that built it. The customer sign-in page is part of your product. It needs your logo, your domain, your wording and the fields your business asks for, and the emails that follow need to come from you.

Authorisation

Employees get access through groups and roles defined by one organisation. Customers in a business-to-business product need a second level: each customer organisation has its own members, its own admins and its own roles, and one customer's admin must never see another customer's people.

What they share

Under the differences sits a common core, which is why the question of one platform comes up at all.

  • Protocols. OAuth 2.0 and OpenID Connect issue the tokens in both cases. SAML 2.0 appears on both sides, as the outbound protocol for workforce single sign-on and the inbound one for enterprise customers.
  • Credentials. A passkey is a WebAuthn credential whether it belongs to an employee or a shopper. See passkeys explained.
  • Sessions and tokens. Both need signed tokens, key rotation, session revocation and lockout after repeated failures.
  • Audit. Both need a record of who signed in, from where, and what was refused.

When one platform for both makes sense

One platform is a good fit when:

  1. The same engineers run both systems and would otherwise learn two consoles, two policy languages and two audit formats.
  2. Your product is business-to-business, so customers bring their own providers and you need federation skills on the customer side anyway.
  3. Employees act inside the customer product, for example support staff viewing a customer account, and you want that on one record.
  4. You are adding AI agents that act for employees and for customers, and want one model for what an agent may do.

Keep them apart, or at least in separate tenants, when:

  1. Different teams own them with different release schedules and risk appetites.
  2. Customer scale is far beyond workforce scale and you need a system tuned only for that.
  3. A regulator requires the two populations to be held separately.

Whichever you choose, keep the two populations in separate directories or projects. A shared platform should mean shared machinery, not one pool of users where an employee and a customer can collide on an email address.

How AuthFI does it

AuthFI treats the two as parts of one platform that share a console, a set of groups and an audit record. Both are included in every plan, and plans are not priced per user.

On the workforce side, AuthFI connects to the directory you already have: providers such as Okta, Microsoft Entra or Google Workspace over SAML 2.0 and OpenID Connect, with accounts created and removed over SCIM 2.0. Applications are opened to groups, and removing someone upstream removes their access. A directory service for Windows and LDAP, and managed Windows devices, are in pilot. Details are on the workforce identity page.

On the customer side, AuthFI provides a hosted sign-in and sign-up page under your brand and your own domain, with the fields you choose. Each business you sell to is an organisation with its own members and roles. A large customer can bring its own single sign-on, routed by email domain, and a small one invites people by email. Sign in with Google is available, and sign in with a phone number is in development. Details are on the customer identity page.

A project lives in one region for life, so customer accounts, sessions and the audit record stay where you put them.

Key takeaways

  • Workforce accounts are owned by the employer and created by a process. Customer accounts are owned by the user and created by them.
  • The lifecycle is where the two diverge most: joiner, mover, leaver on one side, and sign up, recover, delete on the other.
  • Protocols, credentials, sessions, audit and threats are shared, which is what makes one platform possible.
  • One platform suits business-to-business products and small teams. Keep the populations in separate directories either way.