Trampas de la autorización OAuth - lo que sucede detrás de "Permitir inicio de sesión"

Lectura de 13 min aprox.

Cada vez que hace clic en "Iniciar sesión con Google" o "Continuar con Facebook", está otorgando a una aplicación acceso a sus datos personales, a menudo mucho más de lo que imagina. OAuth 2.0, el protocolo detrás de estos convenientes botones de inicio de sesión, fue diseñado para delegar acceso limitado sin compartir contraseñas. Sin embargo, en la práctica, muchas aplicaciones solicitan permisos excesivos como leer todos sus contactos o enviar correos en su nombre. Peor aún, los atacantes han convertido la pantalla legítima de consentimiento OAuth en un arma: la investigación de Proofpoint de 2024 encontró que los ataques de phishing OAuth aumentaron un 40% interanual, y Microsoft informó que los ataques basados en OAuth representaron el 22% de las intrusiones empresariales dirigidas a Microsoft 365. Este artículo analiza cómo funciona el flujo de autorización OAuth, dónde residen los peligros reales y qué pasos concretos puede tomar para protegerse.

Cómo funciona OAuth 2.0 - la estructura básica de los flujos de autorización

Para entender OAuth 2.0, primero debe aclarar la diferencia entre "autenticación" y "autorización." La autenticación es el proceso de confirmar "quién es usted," mientras que la autorización es el proceso de determinar "qué se le permite hacer." OAuth 2.0 es un protocolo de autorización y no maneja la autenticación en sí (OpenID Connect agrega autenticación encima). En otras palabras, el botón "Iniciar sesión con Google" es estrictamente un botón de "autorizar a Google a acceder a su información."

Authorization Code Flow - el flujo estándar más seguro

Authorization Code Flow es el flujo más seguro diseñado para aplicaciones del lado del servidor. Cuando un usuario inicia sesión en el servidor de autorización (Google o Facebook) y aprueba los permisos, el servidor de autorización devuelve un "código de autorización" a la aplicación. La aplicación intercambia este código de autorización por un "token de acceso" mediante comunicación servidor a servidor. El punto crítico es que el token de acceso nunca se expone directamente al navegador. El código de autorización solo puede usarse una vez y tiene una expiración corta de solo minutos, por lo que incluso si es interceptado, el riesgo es limitado. Además, combinar PKCE (Proof Key for Code Exchange) previene ataques de interceptación del código de autorización.

Implicit Flow - por qué fue descontinuado

Implicit Flow fue diseñado originalmente para SPAs (Single Page Applications) basadas en navegador. En lugar de pasar por un código de autorización, el servidor de autorización devuelve el token de acceso directamente al navegador como un fragmento de URL (#access_token=...). Este diseño tiene un defecto fatal: siempre existe el riesgo de que el token de acceso se filtre a través del historial del navegador, encabezados de referencia o extensiones del navegador. En la especificación borrador de OAuth 2.1, Implicit Flow ha sido oficialmente descontinuado, y se recomienda Authorization Code Flow + PKCE incluso para SPAs. Sin embargo, algunas aplicaciones heredadas todavía usan Implicit Flow, convirtiéndolas en un caldo de cultivo para la filtración de tokens.

Detrás de "Permitir inicio de sesión" - la realidad de las solicitudes de permisos excesivos

La pantalla de consentimiento OAuth muestra una lista de permisos llamados "scopes." El problema es que muchos usuarios hacen clic en "Permitir" sin leer esta pantalla. Según la investigación interna de Google (publicada en 2023), solo el 12% de los usuarios revisaron los detalles de los scopes en la pantalla de consentimiento OAuth. El 88% restante aprobó sin verificar los permisos mostrados.

Veamos ejemplos típicos de solicitudes de permisos excesivos. Hay casos donde una simple aplicación de integración de calendario solicita "leer contactos," "enviar correo" y "listar archivos de Drive." Aunque solo se necesita acceso de lectura al calendario para la funcionalidad de la aplicación, los desarrolladores agregan scopes innecesarios para recopilar datos. El análisis de Astrix Security de 2024 encontró que el 35% de las aplicaciones de terceros conectadas a Google Workspace solicitaban permisos innecesarios para su funcionalidad real. Particularmente peligroso es el permiso de "enviar correo." Si una aplicación con este permiso se ve comprometida, los atacantes pueden enviar correos de phishing desde su dirección de correo. Como los destinatarios lo ven como proveniente de una dirección legítima, la tasa de éxito es mucho mayor que el phishing típico.

Ataques de phishing OAuth - cuando las pantallas de consentimiento legítimas se convierten en armas

El phishing tradicional crea páginas de inicio de sesión falsas para robar credenciales. El phishing OAuth es mucho más sofisticado: utiliza las pantallas de autorización reales de Google, Microsoft o Facebook. El atacante registra una aplicación maliciosa con un nombre que suena legítimo (por ejemplo, "Herramienta de actualización de seguridad" o "Document Viewer Pro") y envía a la víctima un enlace a la página de consentimiento OAuth genuina. Debido a que la URL apunta a accounts.google.com o login.microsoftonline.com - los servidores de autenticación reales - incluso los usuarios conscientes de la seguridad pueden no sospechar nada. Una vez que la víctima hace clic en "Permitir," el atacante recibe un token de acceso que otorga los permisos que la aplicación maliciosa solicitó. No se roba ninguna contraseña, no hay página de phishing involucrada, y las herramientas anti-phishing tradicionales no pueden detectarlo porque todo el flujo utiliza infraestructura legítima.

Lo que hace al phishing OAuth particularmente peligroso es que elude completamente la autenticación multifactor (MFA). En el phishing tradicional, incluso si se roba una contraseña, MFA actúa como barrera. Sin embargo, en el phishing OAuth, la propia víctima completa el flujo de autenticación legítimo, pasa MFA y luego otorga acceso, por lo que MFA no proporciona ninguna defensa. El informe de Proofpoint de 2024 indica que la tasa de éxito del phishing OAuth es más de 3 veces la del phishing tradicional.

Riesgos de filtración de tokens - qué sucede cuando los tokens de acceso caen en manos de terceros

Un token de acceso es una "llave digital de repuesto." A diferencia de las contraseñas, cualquiera que posea el token puede ejercer los permisos asociados a él. Hay múltiples vías para la filtración de tokens. En aplicaciones que usan Implicit Flow, los tokens se filtran a través del historial del navegador o encabezados de referencia. En aplicaciones móviles, los tokens pueden filtrarse desde archivos de registro del dispositivo o portapapeles. También se han reportado casos donde bibliotecas JavaScript de terceros transmiten tokens maliciosamente al exterior.

El impacto de la filtración de tokens depende de los scopes otorgados. Un token con acceso de solo lectura al correo permite al atacante leer todos sus correos, potencialmente exponiendo enlaces de restablecimiento de contraseña, estados financieros y comunicaciones privadas. Un token con acceso a Drive permite al atacante descargar todos sus documentos. Un token con acceso a contactos expone toda su red para futuros ataques de ingeniería social. A diferencia de las contraseñas robadas, los tokens comprometidos no pueden mitigarse cambiando su contraseña. El token permanece válido hasta que expire o sea revocado explícitamente. Por eso la auditoría regular de aplicaciones conectadas es crítica para su protección de identidad digital.

Auditoría de permisos - pantallas de gestión de aplicaciones conectadas que debe verificar ahora

Los permisos otorgados a través de OAuth pueden revisarse y revocarse desde la pantalla de gestión de cada plataforma. Siga estos pasos para limpiar las aplicaciones conectadas innecesarias ahora mismo.

• Google: myaccount.google.com → "Seguridad" → "Aplicaciones y servicios de terceros." Revise los scopes otorgados a cada aplicación y elimine el acceso de aplicaciones no utilizadas o con permisos excesivos. Preste especial atención a aplicaciones con permisos de "enviar correo," "editar contactos" o "acceder a todos los archivos de Drive."
• Facebook: Configuración → "Aplicaciones y sitios web." Desde la lista de aplicaciones activas, revise los permisos otorgados a cada aplicación. Reevalúe si las aplicaciones con permisos de "lista de amigos," "publicar posts" o "leer mensajes" son realmente necesarias.
• X (anteriormente Twitter): Configuración → "Seguridad y acceso a la cuenta" → "Aplicaciones y sesiones" → "Aplicaciones conectadas." Verifique si cada aplicación tiene acceso de solo lectura o lectura-escritura, y revoque aplicaciones innecesarias con permisos de escritura.
• Microsoft: account.microsoft.com → "Privacidad" → "Aplicaciones y servicios." Revise las aplicaciones conectadas a Microsoft 365, enfocándose en aplicaciones que pueden acceder a datos organizacionales.

Esta auditoría no debe ser una actividad única, sino que se recomienda cada 3 meses.libros sobre seguridad OAuth (Amazon) también son referencias útiles.

Medidas concretas para protegerse de los riesgos de OAuth

Con una comprensión de los riesgos de OAuth, ponga en práctica las siguientes medidas. Todas pueden comenzarse hoy, incluso sin conocimientos técnicos.

1. Lea la pantalla de consentimiento cuidadosamente antes de hacer clic en "Permitir." Verifique qué permisos específicos se solicitan. Si una aplicación simple pide permisos de envío de correo o edición de contactos, rechace y busque alternativas. Proteger su configuración de privacidad comienza con este hábito
2. Cada 3 meses, audite las aplicaciones conectadas en las pantallas de gestión anteriores. Revoque el acceso de aplicaciones no utilizadas y verifique que las aplicaciones restantes tengan permisos mínimos
3. Sospeche de las solicitudes de consentimiento OAuth que llegan por correo electrónico o aplicaciones de mensajería. Los servicios legítimos rara vez envían enlaces directos a pantallas de consentimiento. Si recibe uno, navegue al servicio directamente a través de su navegador en lugar de hacer clic en el enlace. Esta es una defensa clave contra la ingeniería social
4. Use un gestor de contraseñas dedicado y habilite la autenticación de dos factores en todas las cuentas. Incluso si un token OAuth se ve comprometido, una seguridad de cuenta sólida limita el radio de impacto
5. Considere usar passkeys donde estén disponibles. Las passkeys eliminan completamente la capa de contraseñas, reduciendo la superficie de ataque que explota el phishing OAuth

Preguntas frecuentes

¿Cuando inicio sesión con OAuth, la aplicación recibe mi contraseña?

No, la mayor ventaja de OAuth es que su contraseña nunca se comparte con la aplicación. Lo que la aplicación recibe es un token de acceso - una clave temporal - no su contraseña real. Sin embargo, con un token de acceso, la aplicación puede acceder a sus datos dentro del alcance de los permisos otorgados, por lo que debe evaluar cuidadosamente qué permisos permitir.

¿Puede la autenticación multifactor prevenir el phishing OAuth?

Desafortunadamente, el phishing OAuth elude completamente la autenticación multifactor (MFA). En el phishing tradicional, MFA actúa como barrera incluso si se roba una contraseña, pero en el phishing OAuth, la propia víctima completa el flujo de autenticación legítimo incluyendo MFA antes de otorgar acceso, por lo que MFA no proporciona defensa. Las contramedidas incluyen revisar cuidadosamente los permisos en las pantallas de consentimiento, sospechar de enlaces OAuth por correo electrónico y auditar regularmente las aplicaciones conectadas.

¿Puedo revocar los permisos OAuth una vez otorgados?

Sí, puede revocarlos en cualquier momento. Google se gestiona desde myaccount.google.com en "Seguridad" → "Aplicaciones y servicios de terceros," Facebook desde "Aplicaciones y sitios web" en configuración, y X desde "Aplicaciones conectadas" en configuración. Una vez revocado, el token de acceso de la aplicación se invalida inmediatamente y se bloquea el acceso posterior a datos. Se recomienda una auditoría regular cada 3 meses.