Authentik en pymes: login unico, grupos y auditoria
Un login compartido deja bajas atrasadas y permisos viejos. Guia para instalar Authentik con PostgreSQL, grupos, eventos, backup y prueba de salida.
Un proveedor OIDC recibe una identidad, aplica una politica y devuelve una respuesta firmada. En una pyme que ya usa ERP, archivos, tableros y soporte remoto, cada aplicacion suele guardar usuarios propios con bajas atrasadas. Authentik centraliza aplicaciones, grupos, eventos y permisos sobre PostgreSQL. La guia explica que se instala primero, donde vive cada dato y como probar una baja antes de sumar mas sistemas.
Donde aparece el usuario duplicado
La cifra que corrige la rutina esta en la auditoria: Authentik registra eventos y su retencion predeterminada es de 365 dias. Un usuario local que queda activo durante un año deja una huella larga, aunque nadie mire el panel. Esa memoria sirve para revisar ingresos, cambios de grupos y fallas de autenticacion.
La baja tardia suele ser mas cara que el alta prolija.
El dato global muestra por que el login dejo de ser un asunto menor. Octoverse 2025 informo mas de 180 millones de desarrolladores y 630 millones de repositorios. Incluso una organizacion chica acumula aplicaciones, APIs, tableros y repositorios. Cada alta manual agrega una cuenta que despues alguien debe encontrar.
La cuenta local sobrevive al proveedor
El antagonista es el usuario creado a mano dentro de cada aplicacion. En un colegio profesional de Cuyo con 1.800 matriculados, administracion puede tener Nextcloud, mesa de ayuda, sistema contable y tablero de cobranza. Una credencial impresa queda dentro de una funda plastica junto a la credencial de matricula; el sistema necesita saber si esa persona sigue en su rol.
Authentik separa identidad, aplicacion y politica. El administrador crea usuarios y grupos. La aplicacion recibe una respuesta OIDC, SAML o proxy. La politica decide acceso segun grupo, atributo o flujo. La pagina de primeros pasos muestra aplicaciones y proveedores; la documentacion de configuracion detalla variables para PostgreSQL, Redis y secretos.
Como funciona por dentro
El flujo minimo tiene siete pasos. Primero, IT instala servidor, worker, PostgreSQL y Redis con Docker Compose. Segundo, administracion crea grupos por area, proveedor o comision. Tercero, cada aplicacion se registra con proveedor OIDC, SAML o proxy. Cuarto, Authentik valida usuario, grupo, MFA y politica. Quinto, PostgreSQL 17 guarda usuarios, grupos, aplicaciones, sesiones, eventos y auditoria. Sexto, el tablero muestra eventos recientes y fallas. Septimo, el backup copia base, secretos y configuracion, y se prueba restaurando una aplicacion real.
PostgreSQL guarda registros estructurados, usuarios, grupos, politicas y eventos. Authentik recibe credenciales y atributos, entrega una respuesta firmada a cada aplicacion y deja eventos consultables. Redis guarda tareas y colas de trabajo temporales. El monitoreo revisa servidor, worker, base, Redis, certificados y vencimiento de secretos. Si falla Authentik, el ingreso central cae. Si falla la base, se pierden usuarios y reglas. Si falla Redis, algunas tareas llegan tarde.
Los permisos se administran con roles y objetos. La documentacion de permisos separa permisos globales y permisos por objeto. IT administra proveedores y politicas. Administracion puede pedir altas. Gerencia lee reportes. Proveedores tienen grupos con fecha de baja.
Que se instala o configura primero
La pila inicial usa Authentik, PostgreSQL 17, Redis, HTTPS, correo saliente, grupos, MFA para administradores, exportacion de configuracion y backup diario. El piloto cuesta entre USD 1.200 y USD 3.600, entre ARS 1,70 y 5,10 millones al dolar vendedor oficial de $1.417 informado por Bluelytics. Incluye instalacion, dos aplicaciones, grupos, documentacion de baja, eventos y restauracion.
El plazo va de dos a cinco semanas. UMSA suele pedir un entregable verificable: veinte usuarios, cinco grupos, dos aplicaciones conectadas, MFA activo para administradores, un proveedor externo con vencimiento, un reporte de eventos y una restauracion completa. El costo incluye roles, pruebas y traspaso; no incluye licencias de las aplicaciones conectadas.
La primera decision es el nombre de los grupos. Area, funcion y vencimiento deben leerse sin preguntar. Un grupo llamado soporte-proveedor-2026-06 dice mas que un permiso suelto dentro de una aplicacion.
La segunda decision es la salida. Cada baja debe cortar sesion, quitar grupo, registrar fecha y dejar evento visible. El reporte semanal lista usuarios sin ingreso reciente, proveedores por vencer y aplicaciones sin dueño.
La migracion conviene hacerla por aplicacion, no por toda la empresa de una vez. Primero se conecta una herramienta de bajo riesgo, se revisan grupos y eventos, y despues se suma el sistema con datos sensibles. Cada avance deja una captura de configuracion, una prueba de ingreso y una prueba de rechazo.
Donde se rompe y como probarlo
Primer riesgo: grupos demasiado amplios. La señal aparece cuando un usuario nuevo ve aplicaciones ajenas. La prueba crea tres perfiles y fuerza ingreso permitido, ingreso denegado y baja. Segundo riesgo: MFA solo para algunos administradores. La señal es una cuenta con permiso alto y segundo factor ausente. La prueba revisa roles y exige MFA a todo perfil de administracion.
Tercer riesgo: backup sin secretos. La señal aparece al restaurar usuarios y perder proveedores. La prueba recupera base, variables y certificados en un entorno aislado. Cuarto riesgo: eventos sin revision. La señal es una semana sin lectura del panel. La prueba exporta eventos y confirma usuarios, fechas, IP y aplicacion. El login unico sirve cuando tambien corta accesos viejos.