One Login for Everything: SSO on Your Own Server
The Problem Is Not One Bad Password
Most small companies do not have one login problem. They have twenty.
A new employee gets mail, file storage, photos, a password vault, monitoring, a VPN, maybe a Git repository, and a few tools added later. Each service asks for its own password. Some end up saved in browsers. Some get shared in chat. Some still work after a person changes role or leaves.
That is an attack path. Verizon’s 2025 Data Breach Investigations Report says the human element was involved in about 60% of breaches, and stolen or misused credentials remain one recurring way attackers get in (Verizon DBIR). CISA’s practical advice follows from the same lesson: use long, random, unique passwords kept in a password manager, because one reused password can put several accounts at risk (CISA).
Password sprawl is unmanaged access.
What Single Sign-On Changes Day to Day
Single sign-on does not mean “one weak password opens everything.” Done properly, it means one identity system decides who you are, how strongly you must prove it, and which applications you may enter.
A self-hosted identity provider such as Authentik or Keycloak can fill that role. How far SSO reaches depends on each application’s integration and support for modern login standards, such as OAuth2, OpenID Connect, or SAML — services like Nextcloud for files, Immich for photos, and Gitea for code, where those integrations are enabled. Vaultwarden accepts an OpenID Connect provider once SSO is enabled for it. Mail protocols such as IMAP and SMTP predate web-style sign-on, so desktop and mobile mail clients keep their own credentials even where a web interface uses a central login.
For the team, the visible change is deliberately unremarkable:
- one account to create,
- one place to reset access,
- one policy for two-factor login,
- one list of groups that decides who sees what.
The password vault still stores secrets for the places that cannot use SSO, and each app keeps its own internal rules. But the first gate is shared: fewer passwords, fewer forgotten accounts, fewer places to clean up by hand.
Stronger Login Without More Ceremony
The second benefit is that stricter login rules become realistic. Asking everyone to configure two-factor login five times over is how security advice gets ignored. Asking once, at the identity layer, is much easier to live with.
The standards underneath are well established. OAuth 2.0 was published as RFC 6749 in 2012 (RFC 6749); OpenID Connect 1.0 was finalized in 2014 (OpenID Connect Core); time-based one-time passwords are specified in RFC 6238 (RFC 6238); and passkeys are WebAuthn-based credentials stored on a device or security key rather than remembered as text (W3C WebAuthn).
What actually happens when you click “log in” is a fixed sequence, the authorization code flow, defined by RFC 6749 §4.1 and extended by OIDC Core §3.1:
- Your browser is sent to the identity provider’s authorization endpoint, carrying the application’s client ID, the requested scope (OIDC requests must include the
openidscope value), and a redirect URI. - The identity provider authenticates you — password, second factor, passkey, whatever the policy requires — and asks you to approve access if needed.
- If you approve, the identity provider redirects your browser back to the application with a short-lived authorization code attached.
- The application’s server exchanges that code for tokens at the provider’s token endpoint, authenticating itself directly to the provider (not through your browser).
- The provider validates the code and the app’s credentials, then returns an access token and, for OIDC, an ID token identifying who you are.
- The application validates the ID token and reads your identity from it, rather than trusting a username the browser handed it directly.
Your browser only ever sees steps 1–3; the tokens in steps 4–5 pass directly between the application’s server and the identity provider, “without passing [them] through the resource owner’s user-agent,” as RFC 6749 §1.3.1 puts it.
Self-hosted identity providers implement these same standards: Authentik’s documentation, for example, covers OAuth2/OIDC and SAML providers alongside user and group management (Authentik documentation). An application that speaks any of them can usually be pointed at one.
For a business, the point is control: you can require stronger proof from the admin group than from a read-only account, and change a rule once instead of visiting every app’s settings page.
Offboarding Should Take Minutes
Offboarding is the harder access problem.
When someone leaves, a manager usually remembers email and maybe the shared drive. But the photo library? The VPN account created six months ago? The test Git repository? The old admin login made during migration?
With SSO, the checklist gets shorter: disable the person in the identity provider, remove them from groups, rotate any shared secrets they could see, and check the audit trail.
That does not end every session at once, and it is worth understanding why. Access tokens are meant to be time-limited — RFC 6749 §5.1 recommends the response state how long a token lasts (expires_in; the RFC’s own worked example is 3600 seconds) — and every OIDC ID token is required to carry an expiration claim, exp (OIDC Core §2). Disabling the account stops the identity provider from issuing new tokens or renewing old ones, but it does not by itself invalidate a token that was already handed to an application and has not yet expired. Some providers add token revocation or back-channel logout to close that window; whether a given application honours them is worth checking before you rely on it. A short-lived token closes itself out fast; a longer-lived one needs its expiry checked. Some tools also cache access outside any token’s lifetime, some secrets still need rotation, and shared mailboxes need a written procedure. But the difference is large: you are no longer hunting through ten admin panels hoping you remembered them all, and you know exactly what “not fully closed yet” means instead of guessing. The realistic target is minutes for the account itself, plus whatever the longest outstanding token’s lifetime is.
Your Server, Your Identity
Putting SSO on your own server is a small change with a large business effect. Access becomes visible. Stronger login becomes practical. Leaving the company becomes a controlled process instead of a memory test.
Principale does not install an identity provider yet — Authentik and Keycloak are on the roadmap. Nextcloud can already connect to an OpenID Connect provider you run yourself, through its OpenID Connect app configured by you, and how far SSO reaches depends on each application’s own integration.
principale.dev installs apps such as Nextcloud on a server you own. Every install is free. See how it works.