Homelab SSO: Authentik vs Authelia vs Pocket ID

Quick Answer

Choose a homelab identity provider from the protocols your applications actually support. Pocket ID targets passkey-first OIDC; Authelia covers proxy access control and documented OIDC integration; Authentik offers a wider mix of providers and identity flows. Start with one low-risk app and prove normal and denied access, authenticator recovery, and local emergency administration while the provider is down. Single sign-on centralizes a dependency as well as login; keep its recovery instructions and credentials independently accessible.

The Reader Question

Should I put one login system in front of my self-hosted apps?

This comparison is for a home or small-team operator who controls DNS, TLS, and the reverse proxy and wants to centralize human sign-in. Inventory each app's native OpenID Connect (OIDC), Security Assertion Markup Language (SAML), Lightweight Directory Access Protocol (LDAP), or proxy-auth support first. Service accounts, API tokens, and emergency local administrators remain separate from human single sign-on.

Before You Start: Safe Defaults

• Keep admin break-glass accounts for the reverse proxy, hypervisor, password manager, and identity provider.
• Do not put the only documentation or password vault behind the SSO system it documents.
• Use MFA or passkeys for the SSO account before exposing it to the internet.
• Start with one non-critical app before moving DNS, backups, media, or Home Assistant behind SSO.

Reference Model

The reference model below shows the practical order for homelab sso authentik vs authelia vs pocket id. Open each step for the operational detail behind the diagram.

Interactive reference model

Homelab SSO: Authentik vs Authelia vs Pocket ID reference model

Read the model left to right, then open each step below for the operational detail behind the diagram.

Plan Control Change Verify

01List apps+

Record which apps support OIDC, SAML, LDAP, headers, or no SSO.

Output: document the evidence from this step before moving to the next one.

02Choose IdP+

Pick the simplest identity provider that supports the protocols you need.

Output: document the evidence from this step before moving to the next one.

03Place proxy+

Decide where SSO checks happen: app, proxy, or both.

Output: document the evidence from this step before moving to the next one.

04Test lockout+

Prove break-glass access before enforcing policy broadly.

Output: document the evidence from this step before moving to the next one.

Decision Matrix

Choice	Best Fit	Watch Point
Pocket ID	Simple passkey-first OIDC for modern apps	OIDC-focused; not the broadest enterprise protocol set.
Authelia	Reverse proxy protection, policy-driven access, and documented OIDC integration	YAML/config discipline and app integration limits.
Authentik	Complex homelab or small-team identity workflows	More moving parts and admin surface.
No central SSO yet	Small trusted LAN with few apps	Password sprawl grows quickly.

Choose by Protocol, Not Vibes

OIDC is common in newer self-hosted apps. SAML and LDAP show up when apps are older or more enterprise-oriented. Proxy auth is useful when the app itself cannot speak SSO cleanly. The product choice should follow those requirements.

Pocket ID is attractive when you want a passwordless, passkey-first OIDC provider. Authelia is strong when the reverse proxy is the enforcement point. Authentik is the broadest tool when you need providers, outposts, LDAP, SAML, or more elaborate flows.

As checked October 2, 2026, Authentik supports the latest patches of its 2026.5 and 2026.8 trains. Authelia documents an OIDC provider in open beta, so it is not limited to proxy authentication. Check the exact protocol and client integration against the selected release; roadmap labels and a feature list do not prove that an app's claims, sessions, or logout work.

CVE-2026-40166 allowed authenticated non-admin users with an OAuth access token to read confidential client secrets for providers they had previously used. Authentik lists 2025.12.5 and 2026.2.3 as the historical fixes for that issue, not as current installation targets. Upgrade through a supported path to a supported patched release. For a potentially exposed instance, inventory affected providers, rotate possibly exposed secrets, revoke relevant sessions and tokens, preserve and inspect events, and retest relying applications; patching does not retract a leaked secret.

The Request Path

In proxy-protected access, the proxy checks authorization before forwarding a request to the app. With native OIDC, the app is a relying party: browser redirects and the app's exchange with the identity provider establish its own session. Record which model each app uses, which headers it trusts, and where access is enforced. Monitor that entire path, and keep emergency administration constrained to authorized operators rather than creating an unrestricted bypass.

Recovery and Family Use

SSO should make daily access easier, but recovery must stay boring. Keep backup MFA methods, recovery codes, second security keys, emergency admin users, and a written procedure for what happens if the IdP VM is down.

• Use passkeys or security keys for admin identity.
• Keep one local admin path per critical app where supported.
• Document callback URLs, client secrets, proxy headers, and group mappings.

Identity and Break-Glass Pilot

Pilot the selected provider with one low-risk app that supports native OIDC. Use a normal user and an administrator, a fresh browser, and a second device. Test enrollment, login, logout, session expiry, denied group access, lost-authenticator recovery, IdP outage, DNS failure, and local break-glass access before adding a critical app.

This comparison is documentation-backed; TechGeeks did not independently deploy the current releases or measure resource use, protocol interoperability, or failover. Run the pilot with the exact reverse proxy and client applications because forwarded-header trust, claim mapping, browser passkey support, and logout behavior vary.

Implementation Details

Begin with one native-OIDC low-risk app and two roles. Establish TLS, callback URLs, claims, session behavior, and logs before adding proxy auth or complex policy, then stop the IdP and prove the documented break-glass path.

1. Inventory apps and note SSO protocol support.
2. Choose one identity provider and deploy it behind a trusted reverse proxy.
3. Enable MFA/passkeys for administrator accounts.
4. Protect one low-risk app first and test normal login, logout, and session expiry.
5. Add groups and policy after basic login works.
6. Test break-glass access with the IdP stopped.

Evidence and Testing Methodology

• Application inventory with native protocol, callback and logout URLs, group/role claims, local admin path, and service-account exceptions.
• Provider, reverse-proxy, database, outpost, and relying-app versions plus the exact configuration revision.
• Successful and denied login logs, token claims without secrets, session-expiry result, logout result, and rate-limit behavior.
• IdP-down, DNS-down, lost-passkey, second-factor recovery, and local break-glass results from a clean browser.
• Encrypted backup and isolated restore of the provider database/config, with secrets and recovery codes held outside the IdP failure domain.

Validation Checklist

• Users can log in from a clean browser without cached sessions.
• Group-based allow/deny behavior matches the written policy.
• Critical local admin paths still work during IdP outage.
• Audit logs show successful and failed login attempts.
• Backups include IdP config, database, secrets, and recovery notes.

Maintenance Cadence

• Review security advisories and supported-version policy weekly because identity flaws can require secret rotation, not only patching.
• Monthly, inspect failed logins, privileged changes, stale accounts, client secrets, certificates, outpost versions, and backup status.
• After every provider or proxy update, retest one native OIDC app and one proxy-protected app from a fresh browser.
• Quarterly, stop the IdP and execute break-glass access, lost-authenticator recovery, and isolated provider restore without using cached sessions.

Troubleshooting

Symptom	Likely Cause	First Check
Redirect loop	Wrong callback URL, proxy headers, or cookie domain	Compare external URL, app URL, IdP callback, and reverse proxy headers.
User logs in but lacks access	Group claim or policy mismatch	Inspect token claims and group mappings.
Everything locked out	IdP, DNS, reverse proxy, or database down	Use documented break-glass path and restore IdP from backup.

Common Mistakes

• Putting every critical app behind SSO before recovery is tested.
• Exposing the identity provider publicly without MFA and rate limiting.
• Losing OIDC client secrets because .env files were not backed up.
• Confusing authentication with authorization.
• Creating so many policies that no one can tell which rule allowed access.

Useful Gear And Buyer Notes

Identity purchases should improve independent recovery. Compare security-key protocol support, spare-key strategy, device compatibility, firmware lifecycle, physical custody, warranty, and return policy; do not make one key or one mini PC the only way back in.

Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.

• Amazon search: YubiKey security key 2 pack
• Amazon search: password manager family plan
• Amazon search: Intel N100 mini PC server
• Amazon search: UPS USB
• Amazon search: domain name registration

Identity Product Currency Check

This comparison describes protocol and recovery choices, not tested interoperability. Record the actual provider, proxy, database, and app-client versions in the pilot, along with the advisory review date.

Before upgrading or exposing the provider, check its supported release and security advisories, then retest app-specific claims, session expiry, logout, lost-passkey recovery, and the offline emergency path. Retain incident-response steps whenever credentials may already have been exposed.

Related TechGeeks Reading

• Reverse Proxy Setup Without Security Mistakes
• Remote Access Without Opening Router Ports
• How Do You Recover From Losing TOTP, Passkeys, or Password Vault Access?

What This Evidence Does Not Prove

SSO reduces repeated human sign-ins; it does not centralize service accounts safely, authorize users correctly by itself, or protect an application that trusts spoofable proxy headers. OIDC certification or documented protocol support does not prove compatibility with every app's claims, logout, refresh-token, or group-mapping behavior.

A passkey-first design does not eliminate recovery risk: synced passkeys depend on account recovery, device-bound passkeys can be lost, and a single hardware key can fail. The product documentation and independent comparison do not prove uptime, resource use, or incident response in the reader's topology. Central identity also increases impact when DNS, TLS, proxy, database, or the IdP fails.

References

• https://docs.goauthentik.io/security/policy
• https://docs.goauthentik.io/releases/2026.5/
• https://docs.goauthentik.io/security/cves/CVE-2026-40166/
• https://www.authelia.com/overview/
• https://www.authelia.com/roadmap/
• https://pocket-id.org/changelog
• https://pocket-id.org/docs/introduction
• https://homelabcompass.com/compare/authelia-vs-authentik

Final Thought

SSO is successful when users see fewer passwords and the operator still has a tested path in when the identity system is down.