El mayor error con OAuth 2.0 que veo a diario 🔒
Ese simple click de "Iniciar sesión con Google" esconde una coreografía técnica fascinante. Detrás, OAuth 2.0 gestiona miles de millones de autenticaciones diarias, pero muchos desarrolladores aún no comprenden la profun
Artículo
Una lectura sobre tecnología y sistemas digitales, escrita para ir al punto y dejar claras las ideas principales.
Tema principal
seguridad informatica
Fuente
dev.to
Puntos clave
- Ese simple click de "Iniciar sesión con Google" esconde una coreografía técnica fascinante. Detrás, OAuth 2.0 gestiona miles de millones de autenticaciones diarias, pero muchos desarrolladores aún no comprenden la profun
- El problema que OAuth vino a resolver era crítico: antes, las apps de terceros pedían tu contraseña real para acceder a tus datos. Esto no solo otorgaba control total sobre tu cuenta, sino que también era una puerta abie
- La genialidad de OAuth radica en permitir acceso delegado y limitado sin que la aplicación vea jamás tu contraseña. Es una danza de seguridad ingeniosa entre cuatro actores clave:
- Resource Owner: Tú, el usuario, dueño de los datos.
Bloque 1
Ese simple click de "Iniciar sesión con Google" esconde una coreografía técnica fascinante. Detrás, OAuth 2.0 gestiona miles de millones de autenticaciones diarias, pero muchos desarrolladores aún no comprenden la profundidad de su funcionamiento. Este desconocimiento es la raíz de riesgos inesperados.
El problema que OAuth vino a resolver era crítico: antes, las apps de terceros pedían tu contraseña real para acceder a tus datos. Esto no solo otorgaba control total sobre tu cuenta, sino que también era una puerta abierta a desastres si la app sufría una brecha. ¡Revocar acceso era un calvario!
Bloque 2
La genialidad de OAuth radica en permitir acceso delegado y limitado sin que la aplicación vea jamás tu contraseña. Es una danza de seguridad ingeniosa entre cuatro actores clave:
Resource Owner: Tú, el usuario, dueño de los datos. Client: La aplicación (web, móvil, CLI) que solicita acceso. Authorization Server: El proveedor de identidad (Google, GitHub) que te autentica y emite los tokens. Resource Server: La API que contiene tus datos.
Bloque 3
El flujo más robusto y el que deberías usar es el Authorization Code Flow. Tu app redirige al usuario al servidor de autorización para el login y el consentimiento. Tras la aprobación, se devuelve un código temporal a tu backend, que luego lo intercambia por un access token usando un secreto de cliente. La clave de seguridad aquí: ese código es inútil por sí solo sin el secreto del cliente.
Los tokens son tus llaves digitales:
Bloque 4
Access Tokens: Credenciales de corta duración (15-60 min) para llamar APIs. Piensa en ellos como pases de visita temporales. Refresh Tokens: De larga duración. Tu backend los usa para obtener nuevos access tokens sin necesidad de que el usuario se autentique de nuevo, manteniendo la sesión viva de forma segura.
Las scopes (alcances) ofrecen permisos granulares (ej. `gmail.readonly`). Los usuarios saben exactamente qué están aprobando. Siempre aplica el principio de mínimo privilegio.
Bloque 5
Para las apps móviles y SPAs, PKCE (Proof Key for Code Exchange) es indispensable. Resuelve la imposibilidad de guardar un secreto de cliente de forma segura en el dispositivo. Ahora es un requisito en OAuth 2.1.
Los errores son comunes, incluso en producción:
Bloque 6
Almacenar tokens en `localStorage`: Una vulnerabilidad XSS puede robarlos. Usa `httpOnly cookies` o almacenamiento seguro de dispositivos. No validar el parámetro `state`: Abre la puerta a ataques CSRF. ¡Es crucial! Scopes excesivamente amplios: Pide solo lo que necesitas para minimizar el impacto en caso de compromiso. Usar el Implicit Flow: Está deprecado por graves fallos de seguridad. Siempre Authorization Code + PKCE.
OAuth añade una capa de complejidad, sí. Pero la recompensa es incomparable: cero contraseñas almacenadas