A workspace is only one product if it has one front door. How Authentik signs one account into seven products, what multi-tenant identity actually takes, and why the login service gets mail-grade paranoia.
A workspace is only one product if it has one front door. Mail, calendar, files, chat, video, billing: if each of those greets your team with its own password, you haven't bought a workspace, you've bought seven tools and a spreadsheet of credentials. So identity is the pillar everything else hangs on, and it's the one we churned on hardest. Part 4 of the series.
Every product in our stack has its own idea of what a user is. The mail server wants a directory to authenticate against. The chat server wants to be told who belongs to which organisation. The file server creates accounts on first use. The meeting product wants a login token. None of them were designed together, and our job is to make them feel like they were.
The answer is a single identity provider that everything else defers to. We tried two other systems first, ran them long enough to find the walls, and converged on Authentik, which has carried the product since. It speaks the two languages we need: OIDC, the modern single sign-on protocol the web apps use, and LDAP, the directory protocol the mail server expects. One system, one set of accounts, two dialects.
What your team experiences: one account per person, one password, one place to set up two-factor, and the web apps sign you in through the same session. Sign in once in the morning and chat, meetings and the dashboard just open. For desktop mail clients, which speak IMAP rather than browser sessions, each person can create app passwords: separate revocable keys per device, manageable from the dashboard, so a lost laptop never means changing your real password.
Installing an identity provider is an afternoon. Making it safely serve many companies at once is the actual engineering. Every customer at email.eu is an isolated tenant: your people, your groups, your sign-in, invisible to every other tenant. Chat is the clearest example: each customer gets a separate realm with its own history and membership, and each realm trusts sign-ins from exactly that customer's accounts, not anyone else's.
The other thing we learned to do early is treat identity configuration as code. Invitation flows, password recovery, branding, the wiring between apps and the directory: all of it is declared in version-controlled blueprints and applied like any other deployment, rather than clicked together in an admin panel. Clicked-together configuration is how you end up with a login system nobody can rebuild or reason about. Ours can be reconstructed from the repository, and changes to it get reviewed like code changes.
A workspace you can't sign in to is down, whatever the mail queue says. So the login service is engineered to the same standard as the mail cluster. The identity provider runs two replicas. The database machinery underneath it is spread so that no single maintenance event can touch both copies, and the cluster scheduler is told explicitly which pairs are never allowed to go down together, so when our cloud provider rolls machines for routine patching, everything stays quorate and nobody notices. Retry behaviour is tuned so that a brief database interruption stays a blip rather than escalating.
Upgrades get the same paranoia. After any change to the identity provider we walk the full ceremony, sign-in, sign-out, recovery, invitation, because "the upgrade succeeded" and "logins work" are different claims, and only one of them shows up in a deployment log.
You'll rarely see identity on a feature-comparison page, and it decides more of your daily experience than most rows that are on it. It's the difference between onboarding a new colleague in one step or in seven, between revoking a departed employee's access in one place or hunting through admin panels, between a lost phone being an inconvenience or an incident. When you evaluate any workspace, ours included, ask where the accounts live and what happens when that system has a bad day. We've written down our answer.
Next, part 5: the infrastructure underneath all of this, and why we designed it to be as boring as we could manage.