Pocket ID vs Authelia

Do not start from the tools. Start from your application list, because it makes this decision for you in about ten minutes.

Write down every service you want behind one login and mark each one: speaks OIDC, reads proxy headers like Remote-User, or neither. Immich, Grafana, Forgejo, Nextcloud and Paperless-ngx land in the first column. A router UI, an old PHP tool, a dashboard someone wrote in a weekend, and anything you are protecting precisely because you do not trust its own login, land in the third.

If the third column is empty, Pocket ID is the better tool and it is not close: 30 MB idle, one container, ops load 1, and no password anywhere. If the third column has entries, you need something that stops requests, which is Authelia.

The rows that matter here#

Look at ops load and container count. Both are single Go binaries with SQLite, so the specs look almost identical, and the operational difference comes from what each one is wired into.

Pocket ID sits at ops load 1 because nothing is coupled to it: apps redirect to it, it redirects back, and if it is down you cannot log in but nothing else breaks. Authelia sits at 3 because its configuration lives in two places at once, its own YAML and your reverse proxy, and a mistake in either takes down every site behind the proxy.

What each one actually does to a request#

Pocket ID, for an app that speaks OIDC:

1. You open Immich. It has no session, so it redirects you to https://id.example.com/authorize?....
2. Pocket ID asks for a passkey. Your phone or password manager answers it.
3. It redirects back with a code. Immich exchanges it for a token and creates its own session.

The application is logged in. Real single sign-on, in the sense people mean.

Authelia, for any app at all:

1. You open paperless.example.com. Your proxy pauses and calls Authelia's /api/authz/forward-auth endpoint.
2. Authelia checks its session cookie. No session means a redirect to the portal, password, then second factor.
3. The proxy forwards the original request with Remote-User and Remote-Groups headers attached.

The request is authorized. Whether the application logs you in depends entirely on whether it reads those headers. If it does not, your users authenticate at Authelia and then meet a second login form. Say that out loud before you promise anyone single sign-on.

paperless.example.com {
	forward_auth authelia:9091 {
		uri /api/authz/forward-auth
		copy_headers Remote-User Remote-Groups Remote-Email Remote-Name
	}
	reverse_proxy paperless:8000
}

That block is the whole integration for Caddy, and it is also the coupling that Pocket ID has no equivalent of and no ambition to grow one.

What "passkey only" excludes, precisely#

Pocket ID's exclusions are the product, not a roadmap. There is no password login, no SAML, no LDAP server (only inbound sync from one), no forward auth and no proxy outpost. It is on v2.14.0 as of August 2026 after roughly monthly minors, and it passed the OpenID Foundation's conformance suite in 2026, so the part it does do is done properly.

The passkey stance costs two concrete things:

• Credentials are welded to your domain. Change the host in APP_URL and every passkey your users registered stops working simultaneously. Decide the hostname before you invite anyone.
• HTTPS is not optional. WebAuthn requires a secure context, so a plain HTTP deployment on a LAN address cannot register a credential at all. The failure is a browser error that never mentions TLS. Reverse proxy and TLS covers getting a certificate on an internal name.

And one human cost: some of your users will not or cannot use passkeys. There is no password fallback by design. For a household where everyone already has synced credentials through iCloud Keychain, Vaultwarden or 1Password, this is invisible. For a family member on an old Android tablet, it is a support call.

What Authelia's flexibility costs#

Authelia protects anything, which is exactly why it has more sharp edges.

• Sessions are in memory by default. Every restart signs out every user, including anyone mid-way through TOTP enrollment. Adding Redis fixes it and makes your one container two.
• Cookie domains obey the Public Suffix List. You cannot share a session cookie between example.duckdns.org and example-auth.duckdns.org. Free dynamic DNS subdomains hit this wall first, and the only fix is a registrable domain.
• Every bypass rule is a hole. Anything that is not a browser needs one: /remote.php/dav for Nextcloud clients, /api/ for a mobile app, whole subdomains for Jellyfin on a TV. Rules are first-match-wins, so one placed too high silently disables two-factor for everything below it.
• Losing storage.encryption_key is unrecoverable. TOTP secrets and WebAuthn credentials are encrypted at the application layer with a key that lives in your config, not the database. Restore a dump with a different key and everyone re-enrolls.

Pocket ID has the same key-outside-the-database problem in a smaller form: token signing keys are stored encrypted under ENCRYPTION_KEY, so a database backup without it is not usefully restorable. Both belong in a password manager rather than only in the .env file next to the volume.

The OIDC comparison, stated honestly#

Both can issue OIDC, so if your third column is empty you could use either.

Authelia's provider is OpenID Certified and the project still labels it beta: Beta 8, targeted at 4.40.0, with breaking changes that have landed inside minor releases. Authelia has never shipped a 1.0 at all; 4.39.22 is a version string from 2019.

Pocket ID is young (first release 2024) and pre-dates none of that history, but the OIDC issuer is the entire product rather than a second feature, and it is certified too. For pure OIDC, Pocket ID is the more focused implementation and the smaller thing to run.

Where Authelia wins on OIDC is the surrounding machinery: an LDAP directory as a user source, password reset by email, TOTP as well as WebAuthn, and access control rules that apply before the app is reached.

Which one for your situation#

Running both, and why it is clumsier than it looks#

The tempting arrangement is Pocket ID as the OIDC issuer for capable apps, Authelia as the gate for the rest. It works, and it has a cost people discover late: Authelia cannot federate upward to an external OIDC provider, so it cannot use Pocket ID as its user source. You end up with two user stores, two places to add a person and two places to revoke them.

The mitigation is LLDAP underneath as the one place passwords live, with Authelia authenticating against it and Pocket ID syncing users inward from it. That is three services to do what one identity provider does, which is the point at which authentik and its gigabyte start looking reasonable.

What to do next#

Go make the three-column list. It is the only part of this decision that requires knowing anything, and it produces the answer without further reading. Single sign-on for self-hosters walks through it with the header-auth caveats spelled out, The single sign-on gap has the numbers on how many self-hosted apps support OIDC at all, and whichever you pick, put the encryption key in your password manager before you put a single user in the database.