Skip to main content

Autenticación y protección CSRF

OAuth2, sin contraseñas propias​

Los usuarios finales entran con Google o GitHub — ABA nunca almacena ni gestiona contraseñas de usuario. Tras el callback de OAuth, el backend emite su propio JWT de sesión.

El JWT nunca es visible para JavaScript​

El token de sesión se entrega exclusivamente dentro de una cookie HttpOnly / Secure / SameSite — nunca en el cuerpo de la respuesta, nunca en localStorage, nunca legible desde JavaScript del navegador. Esto elimina por diseño el vector de robo de token más común en SPAs: un ataque XSS que lea localStorage no encuentra nada útil ahí, porque el token simplemente no está.

Dónde vive cada cosa
JWT de sesión         → cookie HttpOnly, Secure, SameSite (invisible para JS)
Token CSRF             → cookie XSRF-TOKEN, legible por JS (a propósito)

Como el JWT viaja en una cookie, el navegador la adjunta automáticamente en cualquier request al dominio del backend — incluidos los que un sitio malicioso podría disparar sin que el usuario se entere. La defensa es una segunda cookie, XSRF-TOKEN, que sí es legible por JavaScript: el frontend la lee y la reenvía como header X-CSRF-TOKEN en cada request que modifica datos. Un sitio atacante puede hacer que el navegador mande la cookie, pero no puede leer su valor para copiarlo al header — sin los dos coincidiendo, el backend rechaza el request.

Mensajes de error, antes y después de autenticar​

  • Antes de autenticar: un fallo de login (credencial OAuth inválida, o una API key que no existe/está desactivada) siempre devuelve un mensaje genérico — nunca distingue si el problema fue "la key no existe" vs. "la key está desactivada". Es intencional: no darle pistas a quien esté probando credenciales al azar.
  • Después de autenticar: una vez que el sistema ya confirmó quién sos, los mensajes de error sí pueden ser específicos (por ejemplo, nombrar el límite de cuota exacto que alcanzaste) — a ese punto ya no hay riesgo de filtrar información a un atacante no autenticado.

Defensas adicionales contra fuerza bruta​

Además del flujo OAuth estándar, el backend trackea intentos fallidos de login y aplica una segunda línea de defensa (captcha) tras repetidos fallos — ambos mecanismos con timeouts cortos hacia proveedores externos, para que una caída de un servicio de terceros nunca bloquee el login de un usuario legítimo.

Seguí con Cifrado y Claves para cómo se protegen las credenciales de las bases de datos ya aprovisionadas.