Cómo ordenar SSO interno con authentik 2026.8
Una guía para centralizar accesos con authentik 2026.8: OIDC, grupos, flujos, proxy confiable, PostgreSQL y prueba de salida para pymes argentinas.
Diez aplicaciones con diez claves cuestan menos al principio y más cada vez que alguien se va. En una pyme o cámara empresaria, el gasto real aparece en bajas tardías, accesos compartidos y aplicaciones sin dueño. authentik 2026.8 permite centralizar inicio de sesión, grupos, flujos y proveedores OIDC con una base PostgreSQL; esta guía explica qué instalar, qué dato vive en cada componente y cómo probar la salida.
Dónde aparece el costo de las claves dispersas
El dolor se ve en un alta común: correo, CRM, tablero, repositorio, mesa de ayuda y almacenamiento. Cada sistema guarda su propia contraseña y su propio grupo. Cuando cambia un tesorero o un proveedor, sistemas revisa pantalla por pantalla y espera que nadie haya copiado una clave en un chat. authentik publicó la rama 2026.8 y su release 2026.8.3 quedó disponible el 17 de septiembre de 2026. La documentación de 2026.8 marca tres puntos que importan para una organización chica: certificación OpenID Connect, registro dinámico de clientes y restricción de headers reenviados a redes proxy confiables. En términos operativos, el inicio de sesión deja de depender de cada aplicación y pasa por un punto controlado. La factura repetida de contraseñas es el problema visible. El dato externo ayuda a dimensionar. Stack Overflow recibió más de 30.000 respuestas en su encuesta 2026; 74% de quienes construyen software interno con IA hizo scripts o automatizaciones y 66% trabajó en herramientas internas de equipo. Ese patrón también aparece en cámaras y pymes argentinas: aparecen aplicaciones internas más rápido que los controles de identidad.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, una persona entra con usuario, contraseña y segundo factor si corresponde. Segundo, authentik valida credenciales, grupo, política y flujo; recibe una solicitud de login y entrega un token o una respuesta SAML/OIDC. Tercero, PostgreSQL guarda usuarios, grupos, sesiones, proveedores, eventos y auditoría. Cuarto, Redis sostiene colas y tareas cortas de la aplicación; si falla, se atrasan eventos y trabajos. Quinto, el proveedor OIDC entrega claims a cada aplicación: correo, identificador, grupo y vencimiento. Sexto, el backup copia base, configuración y archivos de medios; una restauración prueba que el login vuelve en otro servidor. El proxy necesita una regla concreta. Desde 2026.8, authentik solo usa headers reenviados cuando llegan desde una red de proxy confiable. Esa configuración evita que una aplicación expuesta acepte origen o protocolo declarados por un cliente cualquiera. Si el proxy queda mal declarado, el usuario ve errores de redirección, enlaces inseguros o sesiones que no cierran. Los permisos viven en dos capas. authentik decide si alguien entra y qué grupo declara. La aplicación decide qué puede leer, editar, exportar o borrar con ese grupo. El traspaso debe quedar escrito en una tabla simple: aplicación, grupo, claim recibido y permiso resultante.
Qué se instala o configura primero
El arranque razonable usa Docker Compose oficial, PostgreSQL, Redis, servidor y worker de authentik, proxy TLS y correo saliente. Un nodo chico alcanza para una primera etapa: entre USD 25 y USD 50 por mes; al dólar oficial vendedor de 1.540 pesos, el rango mensual queda entre 38.500 y 77.000 pesos, sin horas de configuración. Si el SSO cubre aplicaciones de guardia, conviene separar base y proxy en servidores distintos. El primer entregable verificable es una aplicación conectada por OIDC, con tres grupos: administración, operación y consulta. La prueba debe mostrar login, cierre de sesión, alta de usuario, baja de usuario y cambio de grupo. Un piloto lleva una o dos semanas si las aplicaciones ya aceptan OIDC o SAML. UMSA suele entrar cuando la organización ya tiene demasiadas altas manuales. En una cámara empresaria de San Martín, Mendoza, el primer avance útil puede ser chico: un solo portal con SSO, un grupo por rol y un reporte de quién entró durante los últimos 30 días.
Dónde se rompe y cómo probarlo
El primer riesgo está en claims mal nombrados. La señal es que una aplicación recibe el login, aunque no ubica el grupo. La prueba entra con tres usuarios, revisa el token y compara claim, grupo esperado y permiso dentro de la aplicación. El segundo riesgo aparece en proxys. La señal es un redirect a una URL interna o un cierre de sesión que vuelve a abrirse. La prueba simula acceso externo, revisa headers permitidos y verifica que el dominio público sea el único que llega al usuario. El tercer riesgo vive en bajas. La señal es una cuenta que sigue entrando después de salir del grupo. La prueba quita el usuario, corta sesiones activas y vuelve a intentar acceso en cada aplicación conectada. El cuarto riesgo aparece en restauración. La señal es que el servidor levanta, aunque perdió flujos, proveedores o eventos. La prueba restaura PostgreSQL y archivos de medios en otro host, valida un login real y exporta el registro de eventos. El SSO sirve cuando la baja deja una huella: usuario, grupo, aplicación, hora y resultado.
