Authentik en pymes: login unico, grupos y auditoría
Un login compartido deja bajas atrasadas y permisos viejos. Guía para instalar Authentik con PostgreSQL, grupos, eventos, backup y prueba de salida.
Un proveedor OIDC recibe una identidad, aplica una política y devuelve una respuesta firmada. En una pyme que ya usa ERP, archivos, tableros y soporte remoto, cada aplicación suele guardar usuarios propios con bajas atrasadas. Authentik centraliza aplicaciones, grupos, eventos y permisos sobre PostgreSQL. La guía explica qué se instala primero, donde vive cada dato y como probar una baja antes de sumar mas sistemas.
Dónde aparece el usuario duplicado
La cifra que corrige la rutina esta en la auditoría: Authentik registra eventos y su retencion predeterminada es de 365 días. 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 autenticación. 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 más de 180 millones de desarrolladores y 630 millones de repositorios. Incluso una organización chica acumula aplicaciones, APIs, tableros y repositorios. Cada alta manual agrega una cuenta que después alguien debe encontrar.
La cuenta local sobrevive al proveedor
El antagonista es el usuario creado a mano dentro de cada aplicación. En un colegio profesional de Cuyo con 1.800 matriculados, administración 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 matrícula; el sistema necesita saber si esa persona sigue en su rol. Authentik separa identidad, aplicación y política. El administrador crea usuarios y grupos. La aplicación recibe una respuesta OIDC, SAML o proxy. La política decide acceso segun grupo, atributo o flujo. La página de primeros pasos muestra aplicaciones y proveedores; la documentación de configuración detalla variables para PostgreSQL, Redis y secretos.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, IT instala servidor, worker, PostgreSQL y Redis con Docker Compose. Segundo, administración crea grupos por área, proveedor o comisión. Tercero, cada aplicación se registra con proveedor OIDC, SAML o proxy. Cuarto, Authentik valida usuario, grupo, MFA y política. Quinto, PostgreSQL 17 guarda usuarios, grupos, aplicaciones, sesiones, eventos y auditoría. Sexto, el tablero muestra eventos recientes y fallas. Septimo, el backup copia base, secretos y configuración, y se prueba restaurando una aplicación real. PostgreSQL guarda registros estructurados, usuarios, grupos, políticas y eventos. Authentik recibe credenciales y atributos, entrega una respuesta firmada a cada aplicación 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 documentación de permisos separa permisos globales y permisos por objeto. IT administra proveedores y políticas. Administración puede pedir altas. Gerencia lee reportes. Proveedores tienen grupos con fecha de baja.
Qué se instala o configura primero
La pila inicial usa Authentik, PostgreSQL 17, Redis, HTTPS, correo saliente, grupos, MFA para administradores, exportación de configuración y backup diario. El piloto cuesta entre USD 1.200 y USD 3.600, entre ARS 1,70 y 5,10 millones al dólar vendedor oficial de $1.417 informado por Bluelytics. Incluye instalación, dos aplicaciones, grupos, documentación de baja, eventos y restauración. 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 restauración completa. El costo incluye roles, pruebas y traspaso; no incluye licencias de las aplicaciones conectadas. La primera decisión es el nombre de los grupos. Área, función y vencimiento deben leerse sin preguntar. Un grupo llamado soporte-proveedor-2026-06 dice mas que un permiso suelto dentro de una aplicación. La segunda decisión 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 migración conviene hacerla por aplicación, no por toda la empresa de una vez. Primero se conecta una herramienta de bajo riesgo, se revisan grupos y eventos, y después se suma el sistema con datos sensibles. Cada avance deja una captura de configuración, una prueba de ingreso y una prueba de rechazo.
Dónde se rompe y cómo 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 administración. 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 revisión. La señal es una semana sin lectura del panel. La prueba exporta eventos y confirma usuarios, fechas, IP y aplicación. El login unico sirve cuando también corta accesos viejos.