- Centralización de identidades mediante un Proveedor de Identidad (IdP) que elimina la necesidad de múltiples credenciales.
- Simplificación del despliegue en Docker al prescindir de Redis en versiones recientes, optimizando la arquitectura a tres contenedores.
- Protección de servicios mediante Forward Auth y la gestión flexible de protocolos como OAuth2, SAML y LDAP.
- Capacidad de federar identidades externas para permitir el acceso con cuentas de Microsoft Entra ID u otros servicios.
¿Cómo configurar inicio de sesión único SSO con Authentik? Imagina que tienes un montón de servicios montados en tu servidor: un foro, un chat, una nube privada y alguna herramienta de gestión. Lo normal sería que el usuario tuviera que meter su usuario y contraseña en cada una de ellas, lo cual es un engorro tremendo y una pesadilla para gestionar. Aquí es donde entra en juego el Inicio de Sesión Único o SSO, una tecnología que permite que alguien se autentique una sola vez y, ¡tachán!, tenga acceso a todo el ecosistema sin volver a escribir una sola letra.
Para que esto funcione, necesitamos dos piezas clave: un Proveedor de Identidad (IdP), que es el que dice «sí, este usuario es quien dice ser», y un Proveedor de Servicios (SP), que es la aplicación que confía en el IdP. En este sentido, Authentik se posiciona como una solución de código abierto extremadamente potente y flexible, capaz de gestionar identidades y accesos (IAM) en infraestructuras modernas, siendo una alternativa más ligera y manejable que otras opciones como Keycloak para proyectos de tamaño medio.
Arquitectura y despliegue con Docker
A partir de la versión 2025.10, Authentik ha pegado un giro importante en su estructura al eliminar la dependencia de Redis. Antes era obligatorio tenerlo para la caché y las colas de tareas, pero ahora todo ese trabajo lo absorbe PostgreSQL. Esto simplifica el despliegue ya que pasamos de cuatro contenedores a solo tres: el servidor, el worker y la base de datos. Eso sí, ten en cuenta que PostgreSQL ahora trabaja más, por lo que es recomendable revisar el límite de conexiones (max_connections) para evitar cuellos de botella.
Para ponerlo en marcha usando Docker Compose, necesitas un archivo .env donde definas claves fuertes. Es vital generar una AUTHENTIK_SECRET_KEY aleatoria y larga para firmar los tokens de seguridad. El proceso de arranque tiene su truco: lo ideal es levantar primero PostgreSQL, esperar a que el servidor termine las migraciones de la base de datos y, solo entonces, activar el contenedor worker. Si intentas subir todo a la vez en la primera instalación, podrías encontrarte con bloqueos de base de datos que te obliguen a matar sesiones manualmente.
Configuración de Proxy Inverso y Forward Auth
Uno de los casos de uso más habituales es proteger aplicaciones que no tienen un sistema de login propio. Para ello se usa el Forward Auth con Traefik o Nginx. Básicamente, el proxy inverso intercepta la petición y le pregunta a Authentik si el usuario tiene una sesión activa; si no es así, lo manda directamente a la pantalla de login.
Si utilizas Traefik, puedes crear una cadena de middlewares para que añadir protección a un nuevo servicio sea tan sencillo como cambiar una etiqueta en el router. No obstante, hay puntos donde la gente suele tropezar. Por ejemplo, es fundamental que el dominio configurado en Authentik coincida exactamente con el que usa el proxy, ya que si hay discrepancias, las redirecciones fallarán y el usuario acabará en un bucle o en una página de error. Además, si quieres que el login funcione en varios subdominios, debes configurar el dominio de la cookie apuntando a la raíz (ej. .miweb.com).
Gestión de Proveedores y Aplicaciones
Cuando configuras el acceso, surge la duda de si usar un proveedor para cada app o uno general. La clave está en entender que el Proveedor (como OAuth2 o SAML) es el «cómo» se autentica el usuario, mientras que la Aplicación es el «donde» accede. Puedes tener un único proveedor OpenID y asociarlo a múltiples aplicaciones, facilitando así la administración.
Para crear un flujo básico, primero defines el proveedor (seleccionando si el flujo de autorización es explícito o implícito) y luego creas la aplicación vinculándola a dicho proveedor. Si necesitas que la aplicación reciba datos específicos del usuario, como el correo o el nombre, debes ajustar los alcances (scopes) del proveedor. Si te olvidas de esto, el usuario entrará en la app, pero esta no sabrá quién es exactamente porque el IdP no le ha enviado la información del perfil.
Integración con Identidades Externas (Office 365 y Azure
A veces no queremos gestionar los usuarios internamente, sino aprovechar cuentas que ya existen, como las de Microsoft Entra ID (antes Azure AD). Para lograr esto, hay que registrar una aplicación en el portal de Microsoft, obtener el Client ID y el Client Secret, y configurar una fuente de federación en Authentik.
El proceso es algo más laborioso porque requiere un mapeo de atributos mediante expresiones. Esto sirve para que Authentik entienda que el campo «mail» de Microsoft corresponde al campo «email» de su propio directorio. Además, es necesario crear un flujo de alistamiento (enrollment) para que, cuando un usuario de Office 365 entre por primera vez, se cree automáticamente su cuenta en el sistema local sin intervención manual del administrador.
Resolución de problemas y mantenimiento
Si después de una actualización el Forward Auth deja de funcionar, lo más probable es que se deba a un cambio en las cabeceras HTTP. Versiones recientes han dejado de soportar X-Original-Uri en favor de X-Original-Url por motivos de seguridad. La solución es actualizar el plugin del proxy inverso para que use la cabecera correcta.
Para diagnosticar fallos en SAML, una herramienta imprescindible es la extensión SAML-tracer para Chrome. Permite inspeccionar los mensajes POST que viajan entre el SP y el IdP, ayudando a detectar si hay algún nombre de atributo mal escrito que esté provocando que el acceso sea denegado. Por último, recuerda no saltar versiones mayor.minor en las actualizaciones; hay que ir paso a paso para evitar que las migraciones de la base de datos rompan el sistema.
Contar con una infraestructura de identidad centralizada permite simplificar la vida del usuario final y reforzar la seguridad del administrador, quien puede controlar accesos granulares y MFA desde un solo panel, ya sea desplegando la solución desde cero con Docker, integrando servicios de terceros como Microsoft o protegiendo aplicaciones mediante proxies inversos.
Apasionado de la tecnología desde pequeñito. Me encanta estar a la última en el sector y sobre todo, comunicarlo. Por eso me dedico a la comunicación en webs de tecnología y videojuegos desde hace ya muchos años. Podrás encontrarme escribiendo sobre Android, Windows, MacOS, iOS, Nintendo o cualquier otro tema relacionado que se te pase por la cabeza.