Identity provider

Your domain users' sign-in is OpenID Connect under the hood, and the provider behind it is yours: an Identity Provider service on a domain you choose.

So "Sign in with your example.com account" is available to any application, with the same identities, passwords, passkeys, and two-factor setup your users already have. Webmail is only the first application you register.

An application can run anywhere

It doesn't have to be on your account. A service on another server, a company's SaaS subscription, and an internal tool behind a VPN all work. Anything that can reach the provider's domain over HTTPS can sign your users in.

What people build on it:

• Single sign-on for self-hosted software. Anything with an OpenID Connect or generic OAuth2 sign-in option can authenticate your users. There's no separate user database, and removing a user in the panel removes their access everywhere at once.
• A sign-in for your own applications. An app server or container you wrote gets production-quality authentication: a password policy, two-factor authentication, passkeys, and session management, none of it built by you. See Connect your application.
• Clients that speak the protocol. A tool can register itself with standard dynamic registration and authenticate your users against the services you host, with nothing created first.

Ordinary email needs none of this

The defaults serve webmail and mail clients with no setup. The management pages are under Email & Identity → OpenID Connect.

Whose sign-in this is

The identity provider signs in your domain users.

It's not how you, the account holder, authenticate; your hosting provider gives you your panel sign-in. The panel's MCP server and REST API have their own built-in credentials and work without an identity provider service.

The provider

An identity provider is a service on a domain, e.g. accounts.example.com. That domain serves both sides of the feature:

Side	What it is
For people	The sign-in portal.
For the protocol	The issuer is https:// plus the domain. An application finds everything else in the standard document at /.well-known/openid-configuration.

The General tab lists all these URLs for copying, and the identity sources: the mail services whose users can sign in through this provider.

Each tenant is separate, by design

The provider authenticates your users for your applications. Their identities work on your domains and nowhere else, and another tenant's users don't exist here.

Protocol support

Modern and strict:

• the authorization code flow with PKCE; no implicit flow, no password grant
• refresh tokens, through the offline_access scope
• the device flow, for clients with limited input

With standard discovery, any current OIDC library sets itself up from the issuer URL.

In this section

Page	Covers
Register applications	Clients, redirect URIs, confidential and public clients, secrets.
Scopes and consent	What an application can learn about a user, and how the user keeps control.
Connect your application	The five values you need, and a working code example.
Dynamic registration	Clients that register themselves, and the guardrails around them.
Supported features	The compatibility reference: endpoints, flows, algorithms, specifications.

The provider's Branding and Style tabs theme everything your users see: the sign-in, consent, and portal pages. See The sign-in portal.