Your workspace already runs an identity system. On Business you can point your own applications at it in about a minute, self-service, with no identity vendor and no second per-user price. How the tenant binding keeps it safe, and the two defaults we narrowed on purpose.
Every company ends up running something that is not part of anyone's suite. A self-hosted GitLab. A project tool. An internal dashboard somebody built. A wiki that predates the current management.
Each one arrives with its own login, and from that day you are running a small identity system by hand. Someone joins and you create four accounts. Someone leaves and you remember three of them. Six months later there is an account belonging to a person who left in spring, still able to sign in, and nobody knows because nobody was looking.
Single sign-on solves this properly. The problem has been that buying it, historically, means an identity vendor, a per-user price on top of your existing per-user price, and a procurement conversation. So small companies do not buy it, and keep managing four logins by hand.
Workspaces come with an identity system already. Ours is open to you.
On the Business plan, an owner or admin can register your own applications for single sign-on, in a form, in about a minute. No ticket to us, no call, no configuration file we edit on your behalf.
You give the app a name and the callback address it will use. We hand back the three things any standard application needs: a discovery URL, a client id, and a client secret. Most software wants only the discovery URL and the two credentials, because the discovery URL is a document describing everything else about how to talk to us. Paste them into the application's settings and your team signs in with their email.eu account.
The protocol is OpenID Connect, which is the modern standard for exactly this and what essentially everything speaks today. We are not asking you to adopt anything unusual. Your application already supports this; it is waiting for you to fill in three fields.
The secret is shown once, at the moment you create it. If it is ever lost or exposed, you rotate it yourself, which mints a new one and immediately invalidates the old. Nothing about that needs us.
Here is the property that makes this safe to offer to every customer on a shared identity system, and the thing to check whenever anyone offers you multi-tenant single sign-on.
Every application you register is bound to your workspace's own group. Only members of your workspace can sign in through it. Not other customers of ours, not anyone else with an email.eu identity, not a stranger who found your callback URL. If someone is not in your workspace, the answer is no, and that decision is made by the identity system rather than by the application trusting us to have been careful.
That binding happens automatically when you create the app. There is no setting to get wrong, because a setting you can get wrong is a setting somebody will get wrong.
Two things we do differently from the out-of-the-box configuration, both worth knowing if you care about this sort of thing.
Only the sign-in flow is enabled. Identity systems typically ship with several ways to obtain a token, including some older ones that involve an application handling your users' passwords directly. We enable the browser-redirect flow and token refresh, and nothing else. Your applications never see a password, because there is no supported path through which they could.
Callback addresses are exact and must be encrypted. We accept only https addresses, and we register them for exact matching rather than as a pattern. Loose matching on callback addresses is one of the classic ways tokens leak to somewhere they should not go, and pattern matching is the mechanism that makes it possible. Being strict here occasionally means you add a second address instead of a wildcard, which is a very small price.
Your applications receive the standard claims: who the person is, their email address, their name, and their group membership. Enough for the application to make its own decisions about who is an administrator, without you maintaining a second list of people.
Worth being precise, because "SSO" gets used loosely.
| Included | |
|---|---|
| OpenID Connect sign-in for your own applications | Yes |
| Your users' name, email and group membership passed to the app | Yes |
| Self-service registration, secret rotation and deletion | Yes |
| SAML | No |
| Creating or removing accounts inside your application for you | No |
We handle authentication. The application asks who this person is, we answer, the person signs in. We do not create or delete accounts inside your application for you. If your tool needs a user record to exist before someone can use it, most of them create one on first sign-in, but that is the application's behaviour, not ours.
This is OpenID Connect, not SAML. Modern software speaks the former. Some older enterprise software wants the latter, and if that is your situation, ask us rather than assuming.
And every registration, rotation and deletion lands in your audit trail, because handing an application the right to authenticate your staff is precisely the sort of change that should leave a record.
Because we already run the identity system your workspace sits on. Signing your people into seven of our own products and refusing to sign them into the eighth thing they use would be a purely commercial boundary, and a transparent one.
The cost of offering it is close to nothing. The value to a twenty-person company that currently maintains a spreadsheet of who has an account where is substantial. So it is part of Business rather than a separate product with its own price per user.
If you want to test it against a specific application before committing, that is a reasonable thing to ask, and we would rather help you check than have you find out afterwards.