Pocket ID vs Authelia

Pocket ID and Authelia are the two small answers to "I want one login for my homelab". Both are a single Go service, both are OpenID Certified, and both fit in 256 MB. They solve different halves of the problem. Pocket ID is an OIDC provider and nothing else: apps that support OpenID Connect send the user to it, and the user proves who they are with a passkey. There is no password to type. Authelia is a forward-auth gate: your reverse proxy asks it about every request, and it answers with a portal that takes a password plus TOTP, a security key, or a Duo push. It is also an OIDC provider, so the overlap is bigger than the one-line descriptions suggest.

Beside your apps vs. in front of them

Pocket ID sits beside your apps. Each app is registered as an OIDC client in Pocket ID's admin UI. The app redirects the user to Pocket ID, the user signs in with a passkey, and the app gets back a signed token. That only works for apps that speak OIDC. Plenty do: Pocket ID's docs carry setup pages for dozens of clients, including Immich, Grafana, Proxmox, Nextcloud and Paperless-ngx. Access control lives on each client. A new client admits no one until you pick the user groups allowed to use it or click Unrestrict.

Authelia sits in front. Traefik's ForwardAuth middleware, Caddy's forward_auth, nginx, HAProxy, Envoy and Skipper all integrate with it. The proxy checks each request with Authelia before serving it, and a visitor without a session is sent to Authelia's portal. The app never takes part, which is why Authelia works in front of software that has no login of its own. Access rules match on subdomain, user, group, request path, method and client network, and each rule chooses between one_factor and two_factor. Apps that trust a proxy header for the user can get it through Authelia's trusted-header SSO.

Passkeys only vs. password plus a second factor

Pocket ID's README is plain about it: it "only supports passkey authentication". A passkey can live in the browser, on a phone, in a password manager or on a hardware key such as a YubiKey. For a user who doesn't have their passkey to hand, Pocket ID documents three fallbacks:

• Sign in with another device. Scan a QR code and approve on a device that does have the passkey. The request expires after 5 minutes.
• Admin login code. Generated from the Users page or with pocket-id one-time-access-token. This is also how a user sets up a first passkey or recovers a lost one.
• Email login code. Optional and off by default. The docs warn that it "is not secure", because anyone with access to the mailbox can get in.

There is no password and no TOTP anywhere in the system. An admin also cannot enrol a passkey for a user. The user has to register their own, usually from a login code or a signup-token link.

Authelia starts from the other end. The first factor is a password, checked against a YAML file of hashed passwords or an LDAP directory. The second factor is a WebAuthn security key, TOTP from an authenticator app, or a Duo push. Password reset by email and lockout after repeated failed attempts are built in. Authelia also supports passwordless login with passkeys, with one catch its FAQ spells out: a passkey counts as a single factor. On a two_factor rule, Authelia asks for the password after the passkey. An experimental option lets passkeys that perform user verification satisfy two_factor on their own. So passkey-only login is possible in Authelia, but it isn't the default.

OIDC: both are providers

Both are OpenID Certified OIDC providers. The difference is how you run them.

• Pocket ID is built around OIDC. You create clients in the web UI, restrict each to groups, and can turn on SCIM provisioning per client, so users and groups are created and removed in the app as they change in Pocket ID. You can also replace the signing key with a larger RSA key, ECDSA or Ed25519.
• Authelia declares clients in its configuration file. Its README calls the OIDC provider comprehensive but says it is "still effectively on the roadmap as a beta". In practice this means one Authelia can gate the apps with no login and also be the OIDC provider for the apps that have one.

Forward auth: Authelia has it, Pocket ID sends you elsewhere

Pocket ID's docs say it directly: "The goal of Pocket ID is to function exclusively as an OIDC provider. As such, we don't have a built-in proxy provider." To put Pocket ID in front of an app with no login, you add an OIDC-aware middleware between the proxy and the app. The docs cover Tinyauth, OAuth2 Proxy, caddy-security, traefik-forward-auth and a Traefik OIDC plugin. That is one more service to configure, but each of those is small.

Authelia isn't on that list, and it can't be yet. Authelia does not accept logins from an upstream OIDC provider. Its roadmap lists the OpenID Connect relying-party role under planning, with every part marked "needs design". So a setup where Authelia guards the proxy and hands sign-in off to Pocket ID's passkeys is not something you can configure today.

Users, groups and LDAP

Pocket ID keeps its own user list. You create users in the admin UI, or Pocket ID syncs users and groups from LDAP (lldap, OpenLDAP, Active Directory) at startup and every hour. Synced users and groups can't be edited in Pocket ID's UI. Signup tokens with an expiry and a use limit let people create their own accounts.

Authelia has no user store of its own beyond the YAML file. Adding a user means editing that file, which can be watched and reloaded, or adding the user in your LDAP server. There is no admin UI. An admin dashboard is on Authelia's active roadmap, described as optional and off by default.

Storage, footprint and configuration

Pocket ID is one container on port 1411. By default it keeps SQLite at data/pocket-id.db. Setting DB_CONNECTION_STRING switches it to PostgreSQL, and files can go to the filesystem, S3 or the database. WebAuthn needs a secure context, so Pocket ID has to be served over HTTPS. After a two-line .env edit, everything else happens in the web UI. If you'd rather keep it in env vars, UI_CONFIG_DISABLED=true makes the environment the source of truth.

Authelia stores its state in SQLite, MySQL, MariaDB or PostgreSQL. Sessions are held in memory by default, and Authelia's own docs warn that a crash loses them. Redis keeps them outside the process and is what a highly available setup needs. The official Lite compose bundle runs Authelia, Redis and Traefik, with users in a file and state in SQLite. Everything is configured in YAML: access rules, session and cookie domains, SMTP, OIDC clients. That's a real advantage if your infrastructure lives in git. It is also where Authelia's 3 / 5 difficulty comes from, against Pocket ID's 2 / 5.

Neither is a resource question. Both have a 256 MB floor, and at idle on first boot Pocket ID measures ~14 MB and Authelia ~30 MB.

Running both, or a pair

The combination that Pocket ID's docs actually support is Pocket ID plus a forward-auth middleware, such as Tinyauth or OAuth2 Proxy. You get passkeys everywhere and one account list: OIDC apps talk to Pocket ID directly, and apps with no login sit behind the middleware, which signs users in through Pocket ID.

Running Pocket ID and Authelia side by side is possible, because both can read the same LDAP directory. It is rarely worth it, though. You get two portals, two sessions and two credentials per person: a password and second factor in Authelia, a passkey in Pocket ID. Most homelabs are better off picking one model.

Which to pick

Pick Pocket ID if…

• Your apps already speak OIDC, and passkeys are what you want people to use.
• You want no passwords to phish, reset or store.
• You'd rather manage users and clients in a web UI than in YAML.
• For the few apps with no login, you're fine adding Tinyauth or OAuth2 Proxy.

Pick Authelia if…

• Several apps have no login of their own and must sit behind your reverse proxy.
• You want password plus TOTP or a security key, per-path rules, and bypass rules for internal networks.
• You want one service that is both the forward-auth gate and the OIDC provider.
• You keep configuration in git and don't want an admin console to secure.

Who should pick neither

If an app needs SAML, or you want login flows you can branch (MFA for one group, an external IdP for another), with enrolment and recovery managed in a UI, both of these are too narrow. That's what authentik is for. See authentik vs. Pocket ID and Authelia vs. authentik for what that breadth costs: a documented 2 GB floor against 256 MB.