Un escritor de XDA recientemente describió cuatro cosas que hizo para asegurar un servidor Plex antes de exponerlo a Internet: aplicar TLS, dejar de anunciar el puerto 32400 directamente a través del router, colocar la cosa detrás de un proxy inverso e habilitar dos factores para la cuenta. Todo tiene sentido. Todo es incompleto. El proxy inverso termina TLS y enruta nombres de host, y luego entrega la solicitud a la aplicación, que se deja decidir por sí misma si la persona al otro lado debe estar allí. Cada servicio termina con su propia página de inicio de sesión, sus propias reglas de contraseña y su propia idea de lo que significa “cerrar sesión”.
Esa es la brecha que llenan las mejores aplicaciones de SSO auto-hospedado. Un proveedor de identidad se sienta detrás del proxy inverso, cada servicio se remite a él, la MFA se aplica una vez para todo, y eliminar el acceso de alguien es un solo botón en lugar de un recorrido por doce paneles de administrador. Observamos 8 opciones que se desarrollan activamente y se ejecutan en laboratorios caseros reales hoy, desde proveedores de identidad completos con su propia base de datos hasta un único contenedor que responde una pregunta sí o no por solicitud.
Qué buscar en una aplicación de SSO auto-hospedado
- Cobertura de protocolos. Si sus aplicaciones hablan OIDC o SAML de forma nativa, un proveedor de identidad es la respuesta limpia. Si la mitad de ellas no habla nada, necesita forward auth también, no en su lugar.
- Si es el propietario de un almacén de usuarios. Algunos poseen cuentas, grupos y hashes de contraseñas. Otros no poseen nada y delegan a algo en la cadena ascendente. Esa decisión impulsa su plan de copia de seguridad.
- MFA que realmente puede aplicar. TOTP es el mínimo. WebAuthn o passkeys es lo que desea para cualquier cosa accesible desde fuera de casa.
- Reglas de acceso basadas en grupos. “Todos los que pueden iniciar sesión pueden acceder a todo” no es control de acceso. Desea una política por aplicación vinculada a la membresía del grupo.
- Lo que le cuesta en RAM y componentes. Un stack de Postgres más Redis más servidor más worker está bien en un NAS con 16 GB. No está bien en una Raspberry Pi que ya ejecuta doce contenedores.
- Un camino de vidrio de emergencia. Cuando el proveedor de identidad está caído, necesita una forma documentada de volver a su propia infraestructura que no dependa del proveedor de identidad.
Comparación rápida
| Aplicación | Mejor para | Almacén de usuarios propio | Protocolos | Forward auth | Licencia |
|---|---|---|---|---|---|
| Authentik | Un proveedor de identidad completo con interfaz web | Sí | OIDC, SAML, LDAP, RADIUS | Sí, proxy outpost | MIT core, paid enterprise tier |
| Authelia | Un portal ligero junto a su proxy inverso | Sí, archivo o LDAP | OIDC provider, forward auth | Sí, native | Apache 2.0 |
| Tinyauth | Obtener cualquier inicio de sesión frente a algunas aplicaciones rápidamente | Sí, más OAuth y LDAP | OIDC, forward auth | Sí, native | AGPL 3.0 |
| LLDAP | Un directorio compartido que otros pueden leer | Sí, solo LDAP | LDAP | No | GPL 3.0 |
| oauth2-proxy | Agregar un IdP existente a una aplicación | No | OIDC y OAuth2 client | Sí, via nginx auth_request | MIT |
| Zitadel | Auditorías y configuraciones multi-inquilino | Sí | OIDC, SAML, SCIM, LDAP | Via OIDC | AGPL 3.0 |
| Keycloak | La cobertura de protocolo y federación más amplia | Sí | OIDC, SAML | Via oauth2-proxy | Apache 2.0 |
| Pomerium | Política decidida por solicitud, no por inicio de sesión | No | OIDC client | Es el proxy | Apache 2.0 |
Por qué la capa de identidad es lo que la gente omite
Las guías de proxy inverso están por todas partes, y terminan en el punto donde el tráfico llega a la aplicación. Las guías de firewall terminan en el puerto. Ninguno responde a la pregunta que importa una vez que un nombre de host es público: quién está permitido, probado cómo y revocado cuándo.
El resultado es un laboratorio casero donde el proxy inverso está bien configurado y las aplicaciones detrás de él están cada una protegidas por lo que su desarrollador envió. Algunos tienen TOTP. Algunos tienen una contraseña de administrador compartida en una variable de entorno. Algunos tienen un asistente de configuración que permanece abierto hasta que alguien lo visita. Un proveedor de identidad delante de todos ellos convierte esa superficie desigual en una puerta, y la puerta es lo único que tiene que hacer bien.
Las aplicaciones
1. Authentik: mejor en general para SSO auto-hospedado
Authentik es en el que terminan la mayoría de los laboratorios caseros, y por una buena razón: cubre ambos lados del problema. Las aplicaciones que hablan OIDC o SAML obtienen un proveedor de identidad adecuado con un punto de conexión de descubrimiento, afirmaciones de grupo y pantallas de consentimiento. Las aplicaciones que no hablan nada obtienen un proxy outpost, que su proxy inverso llama como forward auth y que pasa el nombre de usuario y correo electrónico autenticados como encabezados. Todo se configura a través de una interfaz web, incluido el generador de flujo, que le permite decidir exactamente cuándo se requiere MFA y cuándo se puede reutilizar una sesión. La inscripción, recuperación y restablecimiento de contraseña son self-service, lo que importa cuando alguien que no sea usted necesita una cuenta.
Dónde se queda corto: es el más pesado de las opciones ligeras. La implementación predeterminada es un contenedor de servidor, un contenedor de trabajo, Postgres y Redis, y el proyecto solicita aproximadamente 2 núcleos de CPU y 2 GB de RAM antes de agregar nada. El sistema de flujo es poderoso y en consecuencia fácil de configurar mal, y un flujo de autenticación roto lo bloquea de la interfaz de administrador tan efectivamente como a todos los demás.
Costo: el núcleo tiene licencia MIT y es gratuito sin límites de usuarios. Un nivel de empresa de pago agrega soporte y características orientadas a empresas en lugar de hogares.
Plataformas: Docker o Kubernetes en Linux, y Docker Desktop en Windows y macOS.
Descargar: goauthentik.io · GitHub
Conclusión: ejecute Authentik para SSO auto-hospedado si desea un sistema que maneje tanto las aplicaciones modernas como las que nunca implementarán OIDC, y tiene RAM de sobra.
2. Authelia: opción más ligera con configuración que puede controlar versiones
Authelia es un único binario Go que se sienta junto a su proxy inverso y responde una pregunta por solicitud. Los usuarios viven en un archivo YAML o un directorio LDAP que Authelia no posee, las reglas de acceso viven en el mismo YAML, y toda la configuración es un artefacto que puede enviar a un repositorio privado y restaurar en un minuto. Soporta TOTP, claves de seguridad WebAuthn, push Duo y passkeys, y está certificado como OpenID como proveedor OIDC, por lo que las aplicaciones que hablan OIDC pueden hablar con él directamente en lugar de a través de encabezados. Las integraciones de forward auth están documentadas para nginx, Traefik, Caddy, HAProxy y Envoy.
Dónde se queda corto: no hay interfaz de administrador. Agregar un usuario significa editar un archivo y recargar, lo que está bien para un hogar y es doloroso para cualquier cosa más grande. El restablecimiento de contraseña necesita una configuración de correo que funcione. La sintaxis de registro del cliente OIDC es inflexible, y un error tipográfico en un URI de redirección produce un mensaje de error que no le dice qué extremo está mal.
Costo: gratuito y licenciado bajo Apache 2.0.
Plataformas: Docker o un binario estático en Linux, más Docker en Windows y macOS.
Descargar: authelia.com · GitHub
Conclusión: la opción correcta si sus reglas de acceso son estables, se siente cómodo en YAML y prefiere hacer una copia de seguridad de un archivo que de una base de datos.
3. Tinyauth: mejor para obtener un inicio de sesión frente a las cosas esta noche
Tinyauth es lo que usa cuando Authelia se siente como demasiada ceremonia. Un contenedor, una config y una página de inicio de sesión delante de lo que sea que su proxy inverso le envíe. Maneja usuarios locales, LDAP e inicios de sesión OAuth de proveedores como GitHub y Google, admite TOTP y aplica reglas de acceso por aplicación. La versión 5.1.0 obtuvo la certificación de OpenID para el perfil Basic OP a mediados de 2026, por lo que ya no es solo un shim de forward-auth: las aplicaciones que hablan OIDC pueden usarlo como su proveedor. Las integraciones documentadas cubren Traefik, nginx y Caddy.
Dónde se queda corto: es joven, y el proyecto advierte que los cambios de configuración ocurren frecuentemente entre versiones, por lo que las actualizaciones necesitan leer notas de versión en lugar de extraer una nueva etiqueta ciegamente. No hay SAML, no hay RADIUS y no hay inscripción self-service para personas que aún no están en el directorio. Si su laboratorio casero crece más allá de un puñado de servicios con grupos distintos, lo superará.
Costo: gratuito y licenciado bajo AGPL 3.0.
Plataformas: Docker en Linux, Windows y macOS.
Descargar: tinyauth.app · GitHub
Conclusión: la respuesta honesta más rápida a “no hay inicio de sesión delante de esto en absoluto”, y lo suficientemente pequeño como para costar casi nada ejecutar junto a algo más grande después.
4. LLDAP: mejor para un directorio de usuarios que otros pueden leer
LLDAP no es un portal SSO. Es un pequeño servidor Rust que habla suficiente LDAP para que otro software se autentique contra él, con una interfaz web para administrar usuarios y grupos y una opción para que los usuarios restablezcan su propia contraseña por correo electrónico. Ese alcance estrecho es el punto: Authelia, Authentik, Keycloak, Nextcloud, Jellyfin y una larga lista de aplicaciones auto-hospedadas pueden leer desde él, por lo que obtiene un lugar donde se crean cuentas y un lugar donde se desactivan. Almacena datos en SQLite de forma predeterminada, con MySQL, MariaDB y PostgreSQL como alternativas, y expone una API GraphQL si administra usuarios desde código.
Dónde se queda corto: intencionalmente no es un servidor LDAP completo. Los navegadores LDAP genéricos a menudo fallan contra él, su esquema de hash de contraseña significa que no puede distribuir hashes para que otro servicio valide, y el proyecto nombra a Synology como incompatible. No realiza ninguna autorización por sí solo, por lo que algo más aún debe aplicar reglas de acceso.
Costo: gratuito y licenciado bajo GPL 3.0.
Plataformas: Docker o un binario en Linux, y Docker en Windows y macOS.
Descargar: GitHub
Conclusión: emparejarlo con Authelia o Tinyauth cuando desee un directorio compartido sin implementar un despliegue LDAP real, y omítalo por completo si su proveedor de identidad ya posee sus usuarios.
5. oauth2-proxy: mejor para poner un IdP que ya ejecuta delante de una aplicación
oauth2-proxy no tiene cuentas propias. Es un cliente que envía visitantes a un proveedor OIDC u OAuth2 que ya tiene, verifica el resultado y luego proxies de la solicitud a su aplicación o responde con un sí o un no a la auth_request de nginx. Soporta OIDC genérico junto con integraciones dedicadas para Google, Microsoft Entra ID, GitHub y otros, e implementaciones específicas del proveedor pueden extraer membresía de grupo y reenviarla como encabezados. Es un proyecto CNCF Sandbox y ha estado haciendo silenciosamente este trabajo durante años.
Dónde se queda corto: resuelve exactamente un problema y espera que haya resuelto los otros. No hay administración de usuarios, no hay MFA propia y no hay motor de política más allá de listas de permitidos de correos electrónicos, dominios y grupos. Obtener afirmaciones de grupo a través de una aplicación significa hacer coincidir los nombres de afirmaciones de su proveedor manualmente, y el modo de falla es un inicio de sesión exitoso sin permisos.
Costo: gratuito y licenciado bajo MIT.
Plataformas: Docker o binario en Linux, macOS y Windows.
Descargar: oauth2-proxy docs · GitHub
Conclusión: la opción correcta cuando ya está ejecutando Authentik, Keycloak o Zitadel y necesita que una aplicación terca lo respete.
6. Zitadel: mejor cuando desea una pista de auditoría de cada evento de identidad
Zitadel es una plataforma de identidad Go construida sobre sourcing de eventos, lo que significa que cada cambio a un usuario, un rol o una sesión se almacena como un evento inmutable en lugar de una fila actualizada. Para un laboratorio casero eso suena como sobreingeniería hasta la primera vez que necesita responder cuándo se creó una cuenta y por quién. Cubre OIDC, SAML 2.0, OAuth 2.0, SCIM 2.0 e LDAP, admite OTP por aplicación, correo electrónico y SMS, más U2F y passkeys FIDO2, y es multi-inquilino desde el principio si aloja servicios para más de un hogar o un negocio secundario.
Dónde se queda corto: requiere PostgreSQL 14 o posterior, y la configuración asume que entiende el modelo de organización y proyecto antes de crear su primera aplicación. El diseño API-first es excelente si programa su infraestructura y más pesado que lo necesario si simplemente desea una página de inicio de sesión. El auto-hospedaje es AGPL 3.0, que vale la pena leer si planea construir algo comercial encima.
Costo: gratuito para auto-hospedarse. El servicio alojado se factura por separado.
Plataformas: Docker o Kubernetes en Linux, más binarios para Linux y macOS.
Descargar: zitadel.com · GitHub
Conclusión: elija Zitadel sobre Authentik cuando el registro de estilo de cumplimiento o multi-inquilino sea un requisito real en lugar de una buena idea.
7. Keycloak: mejor para la cobertura de protocolo y federación más amplia
Keycloak es la opción empresarial, ahora un proyecto CNCF con más de una década de uso en producción detrás. Si algún software soporta SSO en absoluto, casi seguramente documenta una integración de Keycloak. Federas contra LDAP y Active Directory existentes, intermediarios a proveedores externos, realizas autorización de grano fino con su propio motor de políticas y manejas las esquinas SAML incómodas que las herramientas más ligeras omiten. Comenzar es genuinamente rápido con start-dev en Docker, que se ejecuta contra una base de datos integrada para evaluación.
Dónde se queda corto: start-dev no es una configuración de producción, y pasar a una significa una base de datos externa, una configuración de nombre de host que tropieza casi a todos la primera vez, y un tiempo de ejecución Java cuyo uso de memoria comienza donde termina Authelia. No tiene modo forward-auth propio, por lo que las aplicaciones que no hablan OIDC o SAML necesitan oauth2-proxy delante de ellas. La consola de administrador asume un vocabulario (realms, clients, mappers) que ninguna guía de laboratorio casero le habrá enseñado.
Costo: gratuito y licenciado bajo Apache 2.0.
Plataformas: Docker o una distribución Java en Linux, Windows y macOS.
Descargar: keycloak.org · GitHub
Conclusión: vale la pena el costo de configuración si necesita federación SAML o está practicando para la misma pila en el trabajo, y es difícil de justificar para seis contenedores detrás de Traefik.
8. Pomerium: mejor para la política decidida por solicitud, no por inicio de sesión
Pomerium invierte el acuerdo habitual. En lugar de un proveedor de identidad que otorga una sesión y un proxy que confía en él, Pomerium es el proxy, y evalúa una política en cada solicitud única utilizando la identidad de un proveedor OIDC ascendente más el contexto sobre la solicitud misma. Las políticas se escriben como configuración en lugar de hacer clic juntas, por lo que las reglas de acceso viven en el mismo repositorio que el resto de su infraestructura. Es sin cliente, lo que significa que nadie tiene que instalar una aplicación VPN para llegar a un servicio interno, y está licenciado bajo Apache 2.0 con un plano de control administrado vendido por separado para organizaciones que desean una GUI.
Dónde se queda corto: no tiene usuarios, por lo que aún necesita Authentik, Keycloak, Zitadel o un proveedor alojado detrás. La implementación típica es más de un contenedor con almacenamiento persistente. Y como reemplaza su proxy inverso en lugar de sentarse junto a él, adoptar Pomerium significa rehacer el enrutamiento y los certificados que ya funcionan, que es mucha interferencia para un laboratorio casero que simplemente desea una página de inicio de sesión.
Costo: gratuito y de código abierto para auto-hospedarse. El plano de control alojado es un producto de pago.
Plataformas: Docker o Kubernetes en Linux, más binarios para Linux y macOS.
Descargar: pomerium.com · GitHub
Conclusión: elija cuando las decisiones de acceso necesiten tener en cuenta más que “esta persona inició sesión hace una hora”, y sobre-ingeniero para cualquier cosa más pequeña.
La fricción que nadie menciona en las guías de configuración
La mitad de sus aplicaciones no hablan OIDC. Forward auth es el fallback: el proxy inverso pregunta al proveedor de identidad, y en caso de éxito pasa encabezados como Remote-User y Remote-Email a la aplicación. Solo funciona si la aplicación puede configurarse para confiar en esos encabezados, y solo es segura si la aplicación no es accesible excepto a través del proxy. Vincule el contenedor a una red Docker interna en lugar de un puerto de host, porque una aplicación que confía en encabezados de identidad confiará en ellos de cualquiera que pueda alcanzarlo directamente.
Cuando el proveedor de identidad está caído, todo está caído. Postgres llena un disco, una actualización de contenedor falla, un certificado vence, y de repente nada en la casa inicia sesión. Decida el camino de vidrio roto antes de necesitarlo: mantenga al menos una ruta a su infraestructura que no atraviese el proveedor de identidad, como SSH sobre una VPN de malla o acceso de consola en la red local, y sepa qué servicio excluiría temporalmente de forward auth para restaurar el resto. Escríbalo en algún lugar que no esté detrás del inicio de sesión que acaba de perder.
Las copias de seguridad deben cubrir el almacén de identidad, no solo la configuración. Para Authelia el estado es un archivo YAML más una pequeña base de datos de registros TOTP y WebAuthn. Para Authentik, Zitadel o Keycloak es una base de datos Postgres más una clave secreta, y restaurar la base de datos sin la clave secreta coincidente le da un servicio que se inicia y luego rechaza cada sesión. Volcado de la base de datos en un cronograma, almacene la clave secreta por separado y pruebe una restauración una vez en lugar de descubrir la brecha durante una interrupción.
SSO delante de un servidor de medios rompe las aplicaciones nativas. Este es el trapense específico en el escenario de Plex. Una aplicación de televisión o un cliente móvil no pueden completar un flujo de inicio de sesión basado en navegador, por lo que colocar forward auth en todo el nombre de host detiene esos clientes de conectarse en absoluto. La solución habitual es excluir las rutas de API de SSO, que tranquilamente lo devuelve a la autenticación del servidor de medios para exactamente el tráfico que lleva su biblioteca. La respuesta más limpia es mantener el tráfico del cliente nativo en una VPN de malla y aplicar SSO solo a la interfaz web, o usar un proveedor de identidad que el servidor de medios soporta directamente en lugar de envolverlo desde afuera.
Nunca haga el proveedor de identidad el vínculo más débil. Su interfaz de administrador debe ser accesible solo desde su red interna o a través de VPN, MFA debe ser obligatorio para cada cuenta que pueda cambiar política, y la verificación de certificados se mantiene en todas partes. Un proveedor de identidad mal configurado es peor que ninguno, porque concentra acceso en lugar de distribuirlo.
Cómo elegir el correcto
- Si desea un sistema que cubra tanto aplicaciones OIDC como aplicaciones solo encabezados: Authentik.
- Si desea toda su política de acceso en un archivo que pueda hacer copia de seguridad y diff: Authelia.
- Si nada tiene un inicio de sesión y desea que se arregle esta noche: Tinyauth.
- Si ya tiene varias aplicaciones que leen LDAP y sin directorio central: LLDAP.
- Si ya ejecuta un proveedor de identidad y una aplicación se niega a usarlo: oauth2-proxy.
- Si necesita una pista de auditoría o aloja servicios para más de un grupo de personas: Zitadel.
- Si necesita federación SAML o desea aprender la pila que su lugar de trabajo ejecuta: Keycloak.
- Si el acceso debe reevaluarse por solicitud en lugar de por sesión: Pomerium.
Para la mayoría de las personas que abren un servidor doméstico a Internet por primera vez, la respuesta honesta es Authentik si el hardware puede llevarlo, y Authelia si no puede. Ambos le dan un inicio de sesión, MFA aplicado y un lugar para revocar acceso, que es todo el punto.
FAQ
¿Cuál es la mejor solución de SSO auto-hospedado para un laboratorio casero?
Authentik cubre la gama más amplia de situaciones, porque funciona como un proveedor de identidad completo para aplicaciones que hablan OIDC o SAML y como una puerta de enlace forward-auth para aplicaciones que no hablan ninguna. Authelia es mejor en hardware limitado o cuando desea toda la configuración en un archivo controlado por versión. Ambos son gratuitos y ambos aplican MFA en cada servicio detrás de ellos.
¿Necesito SSO si mi proxy inverso ya tiene TLS y contraseña?
Resuelven diferentes problemas. TLS protege el tráfico en tránsito y auth básico protege un solo nombre de host con un secreto compartido que no se puede revocar por persona o ser respaldado por MFA. SSO le da a cada persona su propia identidad, aplica un segundo factor una vez para todo, y le permite eliminar el acceso en un lugar. Un proxy inverso es donde se aplica SSO, no un sustituto para él.
¿Puedo poner SSO delante de Plex o Jellyfin?
Parcialmente. La interfaz web funciona bien detrás de forward auth. Las aplicaciones nativas en teléfonos, televisores y cuadros de transmisión no pueden completar un inicio de sesión basado en navegador, por lo que se rompen a menos que excluya las rutas de API, lo que debilita la protección para el tráfico que más importa. Mantenga los clientes nativos en una VPN de malla y proteja la interfaz web con SSO, o use un proveedor de identidad que el servidor de medios integre directamente.
¿Qué pasa si mi proveedor de identidad está sin conexión?
Cada servicio detrás de él deja de aceptar inicios de sesión, y las sesiones existentes vencen en su cronograma normal. Planifique para ello: mantenga el acceso de red local o VPN a su host que no dependa del proveedor de identidad, mantenga una manera documentada de desactivar forward auth en un servicio, y almacene códigos de recuperación y copias de seguridad de base de datos en algún lugar accesible sin iniciar sesión.
¿Es Keycloak excesivo para un servidor doméstico?
Generalmente, sí. Las fortalezas de Keycloak son la federación SAML, brokering a proveedores externos y autorización de grano fino a escala organizacional, y su costo es un tiempo de ejecución Java, una base de datos externa y un vocabulario que debe aprender primero. Para una docena de contenedores detrás de un proxy inverso, Authentik o Authelia entregan el mismo resultado práctico con mucha menos configuración.
¿Estas herramientas almacenan mis contraseñas y cómo las respaldo?
Authentik, Authelia, Zitadel, Keycloak, LLDAP y Tinyauth almacenan credenciales en alguna forma. oauth2-proxy y Pomerium no almacenan nada y delegan aguas arriba. Para los que lo hacen, respaldar la base de datos o archivo de configuración junto con la clave secreta de la instancia, porque una restauración sin la clave secreta coincidente invalida cada sesión y factor segundo inscrito.
