There's a version of dogfooding that's a slogan, and a version where your own employees can't ship code until the bug is fixed. We run the second kind. The Authagonal staff console, the one we use to manage every tenant, authenticates through Authagonal itself: SAML single sign-on from our Entra directory, with SCIM deciding who gets in and what they can do. There is no separate admin password table. We deleted it. If our own SAML is broken, we are locked out of our own product.

That's uncomfortable in exactly the useful way. It turns "SSO is an enterprise feature we support" into "SSO is the only way the people who built this get to work today." Here's what being our own customer caught.

A trimmed build that broke signature verification

We publish the auth server trimmed, to keep the image small. Trimming aggressively deletes code it can't prove is used, and reflection hides usage from it. .NET resolves its XML-signing crypto algorithms by name, reflectively, through CryptoConfig. The trimmer couldn't see those types were needed, removed them, and SignedXml quietly came back unable to build the algorithm. SAML signature verification, the step that proves the login is real, threw a null reference at runtime.

The unit tests passed, because they ran against the untrimmed build where the types still existed. Only the trimmed production artifact failed, and it failed at the exact moment a human tried to sign in. We ship the auth server untrimmed now, with a healthy distrust of trimming anything near reflection-based crypto. If we only supported SAML rather than living on it, this is a customer's incident report instead of ours.

Provisioning is the actual login

Authenticating a user is the easy half of SSO. The hard half is deciding what they're allowed to do and keeping it in sync as people join and leave. We drive that with SCIM: Entra group membership maps to roles, resolved at the moment a token is issued, not copied once at account creation. Add someone to the right group and they have access on their next sign-in; remove them and it's gone. Our own access list dogfoods the exact group-to-role mapping we ship.

That wiring surfaces a class of bug that only exists when authentication and authorization live in two different systems: a just-provisioned admin could authenticate before their role had fully landed, leaving the first sign-in in a valid-but-unauthorized state. The fix is in the provisioning order, not the login, and you only find it by being the new admin signing in for the first time.

A 500 that should have been a 403

The smallest bug was the most embarrassing. When an authenticated user hit something they weren't allowed to, the API returned a 500 instead of a clean 403, because the code path that issues the "forbidden" response depended on a service that wasn't wired up in that host. A denied request is supposed to be a calm, expected outcome, not a server error. Invisible until you're the one getting denied.

The boundary we care about most

Underneath all of it is the one rule a multi-tenant identity platform cannot get wrong: a tenant must never become our admin. We don't trust a single check. The platform is its own issuer and a tenant can't claim its slug; the platform signing key is separate from every tenant's, so a token signed for a tenant can't be replayed as a platform token; and the platform store enforces platform roles independently. Three locks, because the cost of one failing open is the whole product.

The point

None of these were caught by a clever test. They were caught by a person trying to do their job and not being able to. That's the argument for using your own product at the depth where it can hurt you: it converts the bugs hiding in the gaps between systems into bugs you fix before breakfast, because you can't ship until you do.

Everything our console leans on (SSO, SAML, SCIM, MFA, audit logs) is included on every Authagonal plan, not gated behind a tier or metered per connection. See what's included.