Autenticación

Acceder — validar credenciales y devolver el token de acceso y el de renovación

Segundo paso del login — validar código TOTP y emitir tokens

Login social — canjear la aserción firmada del landing por tokens

CR-371 — cierra el login social de las cuentas cuyo portal autentica contra el API. El landing ya probó la identidad (intercambio del código con Google/Facebook, en su servidor) y ya la resolvió contra la tabla de enlaces por `(provider, providerAccountId)`. Lo que llega aquí es ese resultado firmado con el `JWT_SECRET` compartido; no hay contraseña que validar porque nunca hubo una. Por qué el endpoint existe en vez de que el landing se fabrique el `bd_token`: la EMISIÓN de sesión vive aquí — tope de sesiones concurrentes, persistencia del refresh token, política de MFA de la institución, `must_change_password`. Un token fabricado fuera se saltaría las cuatro cosas. Por qué no amplía la superficie de confianza: el `JWT_SECRET` ya es compartido, así que quien pueda firmar esta aserción podría firmar directamente un access token. Las puertas son las MISMAS del login por contraseña a partir de aquí: cuenta activa y segundo factor. La aserción NO puede saltarse el TOTP — si la cuenta lo tiene activo se devuelve el mismo 409 `MFA_REQUIRED` que `/login`.

Cerrar sesión — revocar el token de renovación actual

Devolver el perfil del usuario y su institución

Desactivar TOTP — requiere un código válido

Iniciar enrolamiento TOTP — genera secreto y URI otpauth

Política MFA de la institución (roles obligados a TOTP)

Actualizar la política MFA de la institución

Volver a registrar el autenticador — requiere la contraseña

Genera un secreto NUEVO cuando ya hay uno activo, probando la contraseña. Sin esto, perder el teléfono deja la cuenta en un callejón sin salida: ``/mfa/enroll`` responde 409 si el TOTP ya está activo y ``DELETE /mfa`` exige un código válido, que es justo lo que ya no se puede generar. La única salida era tocar la base de datos a mano. Se exige la CONTRASEÑA, no el código: es el factor que la persona sí conserva, y pedir el que ha perdido sería repetir el callejón. No baja el listón del acceso —quien llega aquí ya tiene sesión iniciada, o sea que pasó contraseña **y** código—; lo que hace es que reemplazar el autenticador cueste probar la contraseña otra vez, en vez de un correo al administrador. El secreto viejo se sustituye y el MFA queda PENDIENTE hasta que ``/mfa/verify`` confirme con un código del autenticador nuevo. Es decir: entre el reinicio y la confirmación la cuenta no se queda sin segundo factor por descuido — se queda sin él a propósito y por unos segundos, igual que en el primer enrolamiento.

Estado MFA del usuario actual

Confirmar enrolamiento TOTP con un código válido

Rotar el token de renovación — revocar el anterior y emitir un par nuevo

Sesiones activas del usuario actual

Cerrar una sesión propia

Revocar todas las sesiones de un usuario (sólo SUPER_ADMIN)