We sell authentication, which makes our scariest question a simple one: when a customer wires their app to us and switches everything on, does it actually work, end to end, on the real thing? Not "do the unit tests pass," but does a brand-new tenant sign up, configure SSO and SCIM and MFA and custom claims and branding, point a real application at it, and log a real user in with the right claims in the token, through a real browser. We answer that the only way we trust: with one end-to-end test that becomes a customer.
It's a single Playwright run, deliberately serial and stateful, and it walks the whole life of a tenant from birth to deletion. One tenant signs up, gets configured to the teeth, serves a real login to a real consumer app, gets backed up and restored, then deletes itself. If any link in that chain breaks, the run goes red, and we don't ship.
It configures everything, not a happy-path slice
The middle of the test is thorough on purpose. It doesn't log in and call it a day; it walks every screen a real implementer touches and exercises it for real: a custom OIDC client with its redirect URIs and token settings, a custom scope that emits user claims, roles and a role assignment, an end user with a custom attribute, a group with real membership and a group-to-role mapping, SAML and OIDC enterprise connections, a SCIM provisioning token, a custom domain, an outbound provisioning app, a teammate invited and re-roled, billing through a real checkout, the audit log with filters and a CSV export, a sandbox environment, and the security, webhook, and email settings (each flipped, then reverted to a safe state). Every one of those is created, verified, and where it makes sense deleted, in the same run.
The point isn't to tick boxes. A customer never uses one feature in isolation; they use a combination, and combinations are where things quietly break. A custom claim only matters if it shows up in the issued token. A group-to-role mapping only matters if the role lands at the exact moment the token is minted. The only way to know is to build the whole thing and then go use it.
The credential dance
Here is the part that makes an end-to-end test of an auth product genuinely awkward: the credentials don't exist when the test starts. You can't hardcode a client secret or a SCIM token, because the entire point is that the tenant mints them, fresh, during the run.
So the test does exactly what a real implementer does, only faster. It creates the OIDC client in the portal and reads back the client id and secret. It mints a Portal API credential in one click and captures it. It generates a SCIM token. Then it feeds each of those freshly-minted secrets into the sample consumer application standing by, rewrites that app's configuration with the new values, rolls it out, and only then drives the actual login. Credentials born in one step get injected into the app under test in the next, and the browser completes a real OIDC redirect against them. The integration is a moving target the test keeps re-aiming at itself as it takes shape.
That consumer is a real deployment, not a mock. When the test verifies a login, a real application really redirected to the tenant's issuer, really got a code back, really exchanged it, and the test decodes the resulting token to confirm the custom claim and the mapped role are genuinely in it. Then it drives the harder edges: a custom-branded login page behind its enable gate, and an enforced webhook that has to block a login the policy denies. A green test on that last one means the deny path works, which is the result you most want to be certain of.
Multi-factor, for real
A password login proves little on its own. The run enrolls and then uses a TOTP authenticator and a WebAuthn credential through a virtual authenticator, so the second factor is exercised the way a real user's is, not stubbed out.
The half everyone skips: getting it back
Most end-to-end tests stop at "it works." Ours keeps going into the parts you only think about at 2am. It takes a backup, deletes the tenant's data out from under itself, restores from that backup, and verifies the configuration and users came back intact. Then it runs a clean self-service delete of the whole tenant. A run leaves nothing behind, which is also how we know that deprovisioning actually deprovisions.
Why this is the test we trust
A wall of green unit tests tells you your functions are correct. This tells you a customer can walk in, build the integration they actually want, with the security features they actually need, and that we can lose their data and hand it back. That is the difference between "the code is correct" and "we can go live."
Every feature this run exercises (SSO and SAML, SCIM, MFA, custom claims and scopes, branding, enforced webhooks, audit export) is in the product at every tier, not gated behind an enterprise upsell. See what's included.
