Historial de versiones

La cuadrícula de métodos de inicio de sesión reemplaza el panel de dos tarjetas en la página de política de seguridad: una fila por método (Contraseña, Passkey, Magic link, Email OTP, Google, GitHub)

password_login_disabled consolidado en security_config.passwordLoginEnabled (la migración V55 rellena automáticamente)

El rail de Seguridad del panel de administración se reestructuró: Política de seguridad, MFA, Passkeys, Sesiones. El portal gana un grupo padre de Seguridad

La página de cambio de contraseña ahora activa correctamente el grupo de navegación de Seguridad

Passkeys / WebAuthn: inicio de sesión sin contraseña mediante biometría del dispositivo (Face ID, Windows Hello) o llaves de hardware (YubiKey). Se registran en el portal y se inicia sesión con un toque o autocompletado condicional

Toggle de passkeys_enabled por tenant y modo solo-sin-contraseña (oculta el campo de contraseña, muestra solo passkey + magic link)

Gestión de passkeys por usuario desde admin: listar credenciales con nombres de dispositivo (búsqueda AAGUID), revocar individualmente, restablecer todas. Nuevo comando CLI reset-admin-passkeys

Passkey con verificación de usuario satisface MFA: los usuarios omiten TOTP al iniciar sesión con una passkey

Defensa contra repetición por credencial mediante el contador de firma WebAuthn; los autenticadores clonados se revocan automáticamente con evento de auditoría PASSKEY_REPLAY_REJECTED

Puerta dura de SMTP impide habilitar el modo solo-sin-contraseña sin la entrega de email configurada

Rate limiting en el endpoint de autenticación por passkey: 10 intentos por 60s por IP, fail-closed en caída de Redis

Indicador de recurso RFC 8707 en el grant authorization_code: los parámetros de recurso se vinculan al código emitido y se propagan al claim aud del access token

Estrechamiento de alcance RFC 9068: las solicitudes de token que apuntan a APIs se estrechan a la intersección de los scopes solicitados y los scopes declarados de las APIs

Editor de scopes en el Admin UI: cada API en el registro del workspace puede declarar sus scopes aceptados, mostrados como badges en línea

La página de Brand Identity del admin se reestructuró en tarjeta de Brand Identity + tarjeta de Visual Theme

Dependencias actualizadas: JUnit 6.1.0, Exposed 1.3.0, imagen base JRE 25

Dos archivos compose en la raíz (docker-compose.yml + docker-compose.prod.yml) reemplazan a los seis que vivían en docker/

El overlay de DB externa se reemplaza por DB_URL en .env; el overlay de demo se reemplaza por KAUTH_DEMO_MODE=true en .env

Toda la guía de despliegue se movió a la documentación; se eliminaron los comentarios del Dockerfile, el Caddyfile y los archivos compose

Inyección de secretos basada en archivos (convención *_FILE) para KAUTH_SECRET_KEY, DB_PASSWORD, KAUTH_REDIS_PASSWORD, KAUTH_BOOTSTRAP_ADMIN_PASSWORD y KAUTH_BOOTSTRAP_API_KEYS

Bloqueo de dependencias de Gradle: gradle.lockfile fija el grafo de dependencias resuelto y CI lo verifica en cada PR

Dependabot habilitado para alertas semanales sobre dependencias de Gradle, GitHub Actions e imágenes base de Docker

Cadena HMAC sobre el registro de auditoría: cada fila lleva prev_hash y row_hash mediante HMAC-SHA256 con clave KAUTH_SECRET_KEY; cualquier manipulación o reordenamiento rompe la cadena

El nuevo comando CLI verify-audit-chain detecta filas de auditoría manipuladas o reordenadas

Los detalles del registro de auditoría ahora usan kotlinx.serialization, corrigiendo la corrupción silenciosa de JSON por cadenas concatenadas a mano

Introspección de tokens multi-audiencia: AccessTokenClaims.aud se amplió para admitir el formato de array

Resource Indicators de RFC 8707 para el grant client_credentials: tokens M2M dirigidos por audiencia con aud vinculado al recurso solicitado

Registro de APIs (admin: /settings/apis): CRUD con alcance de workspace para identificadores de audiencia

Pantalla "Authorized APIs" por cliente con autorización mediante casillas y metadatos de Discovery que anuncian resource_indicators_supported: true

Los recursos desconocidos o no autorizados devuelven RFC 8707 invalid_target 400 en lugar de un token silenciosamente amplio

Los 8 tipos de email transaccional ahora están localizados: verificación, magic link, restablecimiento de contraseña, cuenta bloqueada, invitación, contraseña cambiada, prueba de SMTP y OTP

Las plantillas de email se renderizan en el defaultLocale del workspace con fallback al inglés por clave

Proxy de confianza opcional (KAUTH_TRUSTED_PROXY): evita eludir el rate limiting mediante spoofing de cabeceras

Validación del issuer de JWT: los tokens emitidos por un tenant son rechazados por otro

Prevención de open redirect: el redirect_uri posterior al login se valida contra los valores registrados

La comparación del code verifier de PKCE S256 usa igualdad de tiempo constante

La cabecera Server se suprime de las respuestas HTTP

La normalización de errores de login con igualación de tiempos previene la enumeración de usuarios

El contenedor se ejecuta como non-root (UID 10001) con no-new-privileges, cap_drop: ALL y sistema de archivos de solo lectura

Protección contra replay de TOTP: cada código es de un solo uso por enrolamiento; bloqueo tras un número configurable de intentos fallidos

La validación de variables CSS del tema evita la inyección de valores arbitrarios a través de la configuración del workspace

Tiempos de error de login igualados en las rutas de verificación de contraseña y de TOTP

AdminService se dividió en AuthManagementService, UserAdminService y WorkspaceAdminService

UserSelfServiceService se dividió en UserProfileService y UserSecurityService

Se endureció el ratchet de Detekt: reglas de complejidad y acoplamiento aplicadas en CI

BREAKING: Se eliminó la credencial de admin por defecto. Se genera una contraseña aleatoria en el primer arranque y se registra una sola vez en stdout.

BREAKING: El endpoint de refresh token ahora requiere autenticación de cliente (client_id + client_secret para clientes confidenciales)

BREAKING: Los endpoints de introspección y revocación requieren autenticación de cliente según RFC 7662 / RFC 7009

Detección de replay de refresh token con revocación completa de la familia de sesiones al reutilizarse

Bloqueo de cuenta con umbral configurable e interfaz de desbloqueo para administradores

Login con Email OTP alojado: autenticación passwordless de dos pasos en el navegador (ingresa el email, recibe un código de 6 dígitos, inicia sesión)

Conmutador por tenant para Email OTP desde la configuración del workspace

Primitivas de API de administración send-otp / verify-otp para onboarding passwordless programático

Defensa de bloqueo entre desafíos: umbral de intentos de OTP por tenant con respuesta de tiempo constante

Desajuste del prefijo de las API keys bootstrap: kauth_{slug}_ ahora se aplica de forma consistente en la generación y la validación

Validación de redirect URI más estricta: se requiere coincidencia exacta y se rechazan las variantes con barra final

Especificación OpenAPI actualizada con los endpoints de envío/verificación de OTP y la documentación de filtros del registro de auditoría

Los grupos de filtros del registro de auditoría se muestran en la interfaz de administración para una navegación más clara por categoría de evento

Roles por defecto del cliente: roles por aplicación asignados automáticamente a los usuarios que se autorregistran a través de una aplicación OAuth

Tarjeta de "Registration Defaults" en la consola de administración con menú desplegable y tabla de gestión de roles

Protección contra escalada de privilegios entre clientes: los roles de otras aplicaciones no pueden asignarse como predeterminados

Branding de emails transaccionales: nombre de marca, color, URL del logo, email de soporte y nombre de remitente por tenant

Las 8 plantillas de email transaccional heredan automáticamente el branding del workspace

Tarjeta de editor de branding en la configuración del workspace con vista previa en vivo

Impersonación de admin: actúa como cualquier usuario sin conocer su contraseña, con el claim act de RFC 8693 en el token de sesión

Modelo de doble sesión: la sesión del admin permanece activa por debajo de la sesión impersonada

Revocación en cascada: revocar la sesión del admin también termina la sesión impersonada

Servidor MCP nativo de IA (@kotauth/mcp): 33 herramientas en 8 dominios expuestas vía Model Context Protocol

Control de acceso basado en alcances en cada herramienta MCP: la API key otorga solo los permisos que elijas

Conexión con un comando: npx @kotauth/mcp