Pocket ID vs Authelia vs Authentik: qué SSO elegir para tu homelab

Tienes quince servicios en casa y quince inicios de sesión distintos. Buscas cómo unificarlos y aparecen tres nombres que la gente cita como si fueran intercambiables: Pocket ID, Authelia y Authentik. No lo son. Resuelven problemas parecidos con mecanismos incompatibles, y elegir mal significa descubrir a mitad de la instalación que el proyecto que has montado no puede proteger la mitad de tus servicios. Aquí van los tres modelos, los datos que verifiqué contra las fuentes originales el 30 de agosto de 2026, y una recomendación por escenario.

Puntos clave

• La primera decisión no es qué producto instalas: es qué mecanismo necesitas, si autenticación delegada en el proxy inverso, un proveedor OIDC de verdad o federación completa con SAML y LDAP.
• Pocket ID es un proveedor OpenID Connect certificado que solo admite passkeys, cabe en un binario de Go y exige HTTPS sin excepciones.
• Authelia nació como acompañante del proxy inverso; su proveedor OpenID Connect está certificado y aun así sigue etiquetado como beta abierta.
• Authentik es el único de los tres con SAML, servidor LDAP, SCIM y RADIUS, y también el único que pide PostgreSQL, Redis y 2 GB de RAM.
• La imagen de servidor de Authentik ocupa 356,0 MB comprimidos frente a los 25,6 MB de Authelia y los 30,7 MB de Pocket ID.

Tres respuestas distintas al mismo problema

Cuando alguien dice «quiero SSO en casa» suele estar pidiendo tres cosas que la industria resuelve por caminos separados, y confundirlas es el error clásico de esta comparativa.

La autenticación delegada en el proxy, que en la documentación inglesa aparece como forward auth, funciona antes de que la petición llegue a la aplicación. El proxy inverso intercepta cada solicitud, pregunta a un servicio externo si ese usuario puede pasar y, según la respuesta, deja pasar la petición o redirige a un formulario de acceso. La aplicación protegida no se entera de nada. Por eso este mecanismo sirve para Sonarr, para un panel viejo sin usuarios o para cualquier cosa que jamás vaya a implementar un protocolo de identidad. Traefik lo llama ForwardAuth, nginx lo hace con auth_request y Caddy con forward_auth.

Un proveedor de identidad OIDC es otra cosa. Aquí la aplicación sí participa: sabe hablar OpenID Connect, redirige al usuario al proveedor, recibe de vuelta un token firmado y crea su propia sesión con el usuario y los grupos que vengan dentro. Es mucho más limpio, porque cada aplicación mantiene su noción de permisos, pero exige que la aplicación traiga soporte OIDC de fábrica. Jellyfin, Gitea, Immich, Nextcloud o Grafana lo traen; medio catálogo de servicios domésticos, no.

La federación completa es el territorio empresarial: SAML 2.0 para aplicaciones antiguas, un extremo LDAP para que un equipo pregunte por usuarios como si hablara con un directorio activo, SCIM para dar de alta y de baja cuentas en servicios externos, RADIUS para el wifi y la VPN. Casi nadie necesita esto en casa, hasta el día en que lo necesita.

Qué protocolo habla cada uno

Esta es la tabla que decide la mayor parte de la elección. Todo lo demás son matices.

Pocket ID: un proveedor OIDC que solo entiende passkeys

Pocket ID es el más joven de los tres: el repositorio se creó el 11 de agosto de 2024 y ya acumula 9.057 estrellas. La versión v2.14.0 salió el 18 de agosto de 2026, y desde la v2.7.0 del 11 de mayo han publicado siete versiones menores, así que el ritmo ronda una cada dos semanas. Se distribuye como binario único de Go o como imagen de contenedor, guarda los datos en SQLite por defecto y admite PostgreSQL cambiando la cadena de conexión.

Lo que lo define es la ausencia de contraseñas. No hay campo de contraseña en ninguna pantalla: se entra con una passkey guardada en el navegador, en el móvil, en un gestor de contraseñas o en una llave física. Si un usuario pierde el acceso, un administrador genera un código de acceso temporal desde el panel o desde la línea de comandos. Nada más.

De ahí sale también su restricción más dura, que conviene entender antes de instalar nada: «Pocket ID requires a secure context, meaning it must be served over HTTPS. This is necessary because Pocket ID uses the WebAuthn API», dice su documentación de instalación^[1]. La API de WebAuthn del navegador rechaza cualquier origen que no sea seguro, salvo localhost. Con una IP interna y HTTP plano, Pocket ID sencillamente no funciona.

La segunda restricción es de alcance, y el proyecto la declara sin adornos en su guía de servicios proxy: «The goal of Pocket ID is to function exclusively as an OIDC provider. As such, we don’t have a built-in proxy provider». Es una decisión de diseño, no una carencia pendiente de arreglo. Para proteger algo que no habla OIDC hay que poner delante OAuth2 Proxy, Caddy con el complemento caddy-security o un plugin de Traefik, y esa pieza extra pasa a ser tuya. A cambio, el catálogo de integraciones está muy trabajado: conté 96 guías de aplicaciones en el mapa del sitio de su documentación el 30 de agosto de 2026. El proceso completo está en la guía de instalación de Pocket ID con passkeys.

Authelia: ficheros YAML, forward auth y un OIDC en beta permanente

Authelia lleva desde diciembre de 2016 y es el más veterano y el más estrellado del trío, con 28.742 estrellas. Su descripción oficial lo sitúa con precisión: «an open-source authentication and authorization server providing two-factor authentication and single sign-on (SSO) for your applications via a web portal. It acts as a companion for reverse proxies by allowing, denying, or redirecting requests». Un acompañante del proxy, no un sustituto.

Ese es su punto fuerte. Se integra con Traefik mediante ForwardAuth, con nginx mediante auth_request, con Caddy mediante forward_auth, y también con HAProxy, Envoy, Skipper, SWAG, NGINX Proxy Manager y varios controladores de entrada de Kubernetes. Las reglas de acceso se escriben por subdominio, usuario, grupo, ruta, método y red, y cada regla elige entre uno o dos factores. Para un homelab lleno de servicios sin login propio, este modelo cubre en diez líneas lo que con OIDC exigiría una pieza intermedia por aplicación.

El proveedor OpenID Connect existe y está certificado a los perfiles Basic, Implicit, Hybrid, Form Post y Config, pero el propio proyecto matiza el estado en su README: «While this offering is still effectively on the roadmap as a beta it’s very comprehensive and well implemented already». La documentación de integración repite la etiqueta de beta abierta. Funciona y mucha gente lo usa en producción; simplemente conviene saber lo que dice la etiqueta. SAML 2.0, en cambio, ni existe ni está en desarrollo: figura en la sección de planificación de la hoja de ruta.

En cuanto a factores, Authelia admite llaves FIDO2 y WebAuthn, códigos temporales TOTP y notificaciones push de Duo, y desde hace varias versiones tiene una opción enable_passkey_login que su documentación describe así: «Enables login via a Passkey instead of a username and password. This login only counts as a single factor». Es decir, la passkey sustituye al usuario y la contraseña, y si quieres dos factores tendrás que exigir además otra cosa.

El precio a pagar es la ausencia de interfaz de administración. Todo se configura en un fichero YAML y variables de entorno, se valida con authelia config validate y se aplica reiniciando el servicio. Los usuarios viven en otro fichero YAML o en un servidor LDAP externo. Para quien versiona su infraestructura en Git esto es una virtud; para quien quiere dar de alta a alguien de la familia desde el móvil, no tanto.

Authentik: el proveedor de identidad completo y lo que cuesta

Authentik se presenta como «an open-source Identity Provider (IdP) for modern SSO. It supports SAML, OAuth2/OIDC, LDAP, RADIUS, and more, designed for self-hosting from small labs to large production clusters». La lista de proveedores es la más larga con diferencia: OAuth2 y OIDC, SAML, LDAP, SCIM, RADIUS, proxy con autenticación delegada, acceso remoto, WS-Federation, Microsoft Entra ID y Google Workspace. Está escrito en Python, tiene 25.244 estrellas y la versión 2026.8.0 se publicó el 18 de agosto de 2026 tras siete candidatas entre el 3 y el 10 de agosto.

Su verdadera diferencia frente a los otros dos no son los protocolos, sino el motor de flujos. En Authentik un inicio de sesión es una secuencia editable de etapas: identificación, contraseña, segundo factor, consentimiento, aviso legal, lo que montes. Puedes hacer que un grupo entre con passkey y otro pase por un formulario de aprobación. Esa flexibilidad es la razón por la que la gente lo elige y también la razón por la que se atasca con él: la curva de aprendizaje está en entender flujos, etapas, políticas y enlaces, no en levantar el contenedor. El recorrido básico está cubierto en la guía de instalación de Authentik.

Los proveedores de proxy, LDAP, RADIUS y acceso remoto no corren dentro del servidor principal: necesitan un outpost, que la documentación define como «a single deployment of an authentik component, essentially a service, that can be deployed anywhere that allows for a connection to the authentik API». En la práctica es otro contenedor más por cada uno de esos roles. Y la instalación mínima documentada pide «a host with at least 2 CPU cores and 2 GB of RAM», con PostgreSQL y Redis siempre presentes.

Lo que cuesta mantener cada uno

Las cifras de tamaño las medí yo mismo el 30 de agosto de 2026, leyendo los manifiestos de los registros de contenedores y sumando el tamaño comprimido de las capas de la arquitectura amd64. No son estimaciones de terceros.

La imagen de Authentik pesa 11,6 veces lo que la de Pocket ID y 13,9 veces lo que la de Authelia, y eso antes de contar PostgreSQL y Redis. En un mini PC con 4 GB compartidos entre veinte contenedores, esa diferencia se nota en el arranque y en las actualizaciones. En un servidor con 32 GB, no la vas a percibir.

La otra dimensión del coste es la superficie de configuración. Authelia concentra todo en un YAML que puedes leer entero en diez minutos y versionar en Git. Pocket ID se configura casi solo, con variables de entorno y una interfaz web pequeña. Authentik tiene un panel de administración completo y, con él, muchas más maneras de dejarte algo mal configurado sin darte cuenta.

Qué pasa cuando el proveedor de identidad se cae

Este es el escenario que la gente descubre a la mala, y el comportamiento cambia radicalmente según el mecanismo que hayas elegido.

Con autenticación delegada en el proxy, la caída es total e inmediata. El proxy pregunta a Authelia o al outpost de Authentik antes de cada petición; si nadie contesta, el proxy deniega y todos los servicios que hay detrás quedan inaccesibles, incluidos los que solo querías vigilar de refilón. Un fallo del servicio de identidad se convierte en un fallo de todo el homelab.

Con OIDC puro la caída es más suave. Cada aplicación mantiene su propia sesión después del primer acceso, así que si Pocket ID se cae los usuarios ya conectados siguen trabajando hasta que caduque la sesión local de cada servicio. Lo que se rompe son los inicios de sesión nuevos. Es una diferencia importante a las tres de la mañana.

Después está el bloqueo personal, que es el fallo que de verdad sufre la gente: perder la passkey, cambiar de móvil, formatear el portátil. Cada proyecto tiene su salida de emergencia y conviene probarla el día de la instalación, no el día del susto:

docker compose exec pocket-id /app/pocket-id one-time-access-token admin@ejemplo.es
docker compose run --rm server create_recovery_key 10 akadmin
docker compose exec authelia authelia crypto hash generate argon2 --password 'nueva'

La primera línea es de Pocket ID y devuelve un código de acceso temporal para el usuario indicado. La segunda es de Authentik y genera un enlace válido 10 minutos para la cuenta akadmin; su documentación describe el resultado así: «will output a link that can be used to instantly gain access to authentik as the user specified above». La tercera es lo más parecido que tiene Authelia, porque no dispone de comando de recuperación: genera un hash de contraseña que pegas en el fichero de usuarios antes de reiniciar el servicio. Guárdate además una segunda passkey de administrador en un sitio distinto del habitual, por ejemplo en tu gestor de contraseñas autoalojado, que para eso está Vaultwarden. Y si vas por la vía del proxy, deja preparada una regla de excepción que puedas activar sin pasar por el portal de acceso.

Migrar de uno a otro

La mala noticia primero: los usuarios y los grupos se migran, las credenciales no. Una passkey es un par de claves ligado al identificador de la parte confiante, es decir al dominio del proveedor, y su clave pública vive en la base de datos del proveedor viejo. Los secretos TOTP están ligados al emisor. Cambiar de proyecto significa que cada persona vuelve a registrar su segundo factor. En una familia de cuatro es media tarde; en un grupo de veinte, planifícalo.

La parte del lado de las aplicaciones depende del salto. De un proveedor OIDC a otro se cambia la URL del emisor, el identificador de cliente y el secreto en cada aplicación, y poco más. De autenticación delegada a OIDC hay que tocar cada aplicación una por una para activar su login propio, y algunas simplemente no lo tienen. En sentido contrario, de OIDC a proxy, se pierde la noción de grupos dentro de cada aplicación y se acaba gestionando permisos en dos sitios.

Lo que funciona en la práctica es no migrar de golpe. Levanta el nuevo proveedor en otro subdominio, mueve dos o tres servicios poco críticos, vive con los dos una semana y solo entonces mueve el resto.

Cuál elegir según tu caso

Elige Pocket ID si todo lo que autoalojas habla OIDC, ya tienes certificados válidos y nombres de dominio reales, y te apetece quitarte las contraseñas de encima. Es la opción con menos piezas móviles y la más agradable de usar a diario. Descártala si necesitas proteger aplicaciones sin login propio y no quieres montar un OAuth2 Proxy delante.

Elige Authelia si la mayoría de tus servicios no tienen autenticación decente, ya usas Traefik, nginx o Caddy, y no te asusta un fichero YAML. Es lo que mejor resuelve el problema real de un homelab, que casi nunca es la federación empresarial y casi siempre es «esto no debería estar abierto a internet».

Elige Authentik si necesitas SAML, un extremo LDAP para algo que solo entiende directorios, RADIUS para el wifi, aprovisionamiento SCIM o una interfaz de administración de verdad porque no vas a ser tú quien dé de alta a los usuarios. También si tu homelab es en realidad un laboratorio de prácticas para lo que haces en el trabajo.

Y hay una cuarta respuesta legítima: Pocket ID o Authelia como proveedor OIDC, con OAuth2 Proxy delante de las cuatro aplicaciones tercas que no saben autenticar. Menos elegante sobre el papel, más ligera en la máquina.

Preguntas frecuentes

¿Puedo usar Pocket ID con HTTP en la red local?

No. La API de WebAuthn exige un contexto seguro y solo hace excepción con localhost, así que las passkeys no llegan a registrarse. Necesitas HTTPS con un certificado válido, sea de una autoridad pública o de una interna instalada en todos tus dispositivos.

¿Es Authelia menos seguro por tener su OIDC en beta?

La etiqueta habla de compromiso de estabilidad de la interfaz, no de agujeros conocidos. Authelia está certificada por la OpenID Foundation a cinco perfiles, lo que exige pasar una batería de conformidad. Lo que la etiqueta implica es que algún detalle de configuración puede cambiar entre versiones.

¿Merece la pena Authentik con diez servicios en casa?

Solo si necesitas un protocolo que los otros dos no tienen, o si vas a gestionar usuarios que no eres tú. Para diez servicios y un administrador, el coste de mantener PostgreSQL, Redis, el servidor, el worker y los outposts no se compensa.

Conclusión

La comparativa se resuelve mucho antes de instalar nada. Si tus servicios saben hablar OpenID Connect, un proveedor OIDC pequeño como Pocket ID te da el mejor día a día. Si no saben, la autenticación delegada de Authelia resuelve el problema de verdad con 25,6 MB de imagen y un fichero de configuración. Y si necesitas SAML, LDAP o RADIUS, Authentik es la única respuesta, con sus cuatro contenedores y sus 2 GB de RAM. Prueba el procedimiento de recuperación el mismo día que lo instales: es la parte que todo el mundo deja para después y la única que se usa con prisa. La versión en inglés de este artículo está en Pocket ID vs Authelia vs Authentik: which SSO to pick.

Fuentes

1. documentación de instalación
2. Pocket ID, guía de servicios proxy
3. Pocket ID, recuperación de cuenta
4. authelia/authelia, repositorio y README del proyecto
5. Authelia, guía de integración de OpenID Connect 1.0
6. Authelia, hoja de ruta
7. Authentik, proveedores disponibles
8. Authentik, outposts
9. Authentik, instalación con Docker Compose