Self-service SSO in Auth0 Teams

Single sign-on (SSO) means you sign in once, with your company account, and that one login gets you into every tool your company uses. No separate password per tool.

That is the whole idea. The rest of this post is why companies care so much about it, and what it looks like in practice with Auth0 Teams, the product I work on.

An example company

Say there is a company called Northwind with 2,000 employees. Like most companies, they run an identity provider (IdP) for their workforce, such as Okta, Microsoft Entra ID or Google Workspace. Every employee has one account in it, and that account is the source of truth: who works here, which team they are on, whether they have MFA set up.

Northwind also uses Auth0 to handle login for their own customer-facing apps. Over the years they have ended up with dozens of Auth0 tenants: one per app, plus dev, staging and production for each. Around 80 engineers need access to them.

Without SSO

Each of those 80 engineers has a separate Auth0 login, with its own password.

• When someone joins, an admin invites them by hand.
• When someone leaves, an admin has to remember to remove them. The IdP disables their account on day one, but their Auth0 access lives on until someone notices.
• The security team can’t apply their own rules, like MFA or device checks, because the login doesn’t go through the IdP at all.

The offboarding gap is the one that worries security teams most. A former employee with access to production tenants is exactly what an audit is looking for.

With SSO

Now Northwind connects their IdP to Auth0 Teams. When an engineer signs in:

1. They go to the Auth0 Teams dashboard and enter their work email.
2. They are sent to Northwind’s IdP login page.
3. They sign in there, with the IdP’s MFA and policies.
4. The IdP sends them back to Auth0 Teams with a signed token that says who they are.
5. Auth0 Teams lets them in, to the tenants their role allows.

Steps 2 to 4 are a standard protocol, OIDC or SAML, so the flow is the same whichever IdP the company uses.

Now the problems above go away. A new hire can sign in on their first day. Someone who leaves is disabled in the IdP, and that same moment they lose access to every Auth0 tenant. Security’s rules apply to every login, because every login goes through the IdP.

The self-service part

The part that matters for a product like Auth0 Teams is that the customer sets this up on their own. No support ticket and no waiting.

An admin at Northwind opens the Security page in the Teams dashboard, adds an SSO connection, picks their identity provider, and pastes in a few values from it: the domain, a client ID and a secret. Once it works, they can enforce it, so SSO becomes the only way into the team. New members can be created on their first successful sign-in instead of being invited one by one.

Auth0’s docs walk through it step by step in Configure Security Policies. For background on SSO in general, their single sign-on overview is a good starting point.

Why it matters

For one company, SSO is a convenience. Across 100+ customer environments, each with their own identity provider and dozens of tenants, it is the difference between access that someone has to keep in sync by hand and access that follows the company’s own directory automatically. That is the gap self-service SSO closes.