WorkOS Integration Security Review

An email domain looks like proof of which organisation someone belongs to, but WorkOS’s own guidance says it isn’t: check the organisation from the profile WorkOS returns, not from the domain on the address.

The organisation a login belongs to should come from the profile WorkOS verifies, not the email domain it arrived on

WorkOS Single Sign-On connects your application to an organisation’s identity provider over SAML or OIDC without your team building either protocol. After a user authenticates, your callback endpoint exchanges a short-lived authorisation code, valid for ten minutes, for a Profile containing the user’s identity and the organisation they signed in through. WorkOS’s own SSO guide states plainly that its SSO API is authentication middleware and does not manage your user database, and it warns against validating that profile by email domain, since an organisation can allow guest addresses from outside its own domain. The organisation a login is trusted for should come from the profile’s own organisation ID, checked on every callback, not the domain the address happens to carry.

Trusting that organisation ID also depends on the domain behind it actually being verified. WorkOS’s Domain Verification flow has an organisation’s IT contact add a DNS TXT record before WorkOS marks that domain verified and fires an event to tell your application. Until that event lands, a domain a customer typed into a setup form is a claim, not a fact, and any feature that assumes it, such as auto-joining new sign-ups from that domain into an organisation, should wait for it. Every domain belongs to exactly one organisation, so the question that matters is whether your application actually gates SSO and Directory Sync features on a domain’s verified state rather than on the domain simply being present.

The rest of a WorkOS integration carries its own risk. Directory Sync delivers SCIM provisioning and deprovisioning through webhooks as employees are added, updated or removed in the identity provider, so someone leaving the directory only loses access in your application once your handler consumes that event and disables the account. WorkOS signs every webhook with a WorkOS-Signature header built from a timestamp and an HMAC SHA256 hash, and if your endpoint does not answer with a 200 OK it retries the same event up to six times over three days, so a handler that skips verification or reprocesses a retried event is a real path in. Where AuthKit sessions are used, the access token is a JWT carrying org_id, role and permissions claims that should be checked against the JWKS WorkOS publishes for your client ID on every request, not trusted from an unverified token. A WorkOS secret key reaching client-side code or a public repository hands out server-level access under a plain Bearer header.