OAuth (Open Authorization) es un protocolo que permite a un usuario conceder a una aplicación externa acceso a sus datos sin compartir la contraseña de su cuenta. Permite a los usuarios autenticarse y autorizar a aplicaciones externas a acceder a sus datos y recursos almacenados en un servidor determinado, como la información de su cuenta, fotos y documentos, sin revelar sus credenciales de acceso. OAuth también se utiliza para los inicios de sesión con un solo clic, lo que permite a los usuarios identificarse ante un servicio web sin tener que introducir cada vez su nombre de usuario y contraseña.
Cuando un servicio web se conecta con otro, usan el protocolo OAuth para garantizar una interacción segura que no pida a los usuarios que compartan contraseñas.
Historia
Compartir contraseñas nunca es recomendable para ninguna aplicación. Por eso, grandes empresas tecnológicas como Google y Twitter introdujeron una solución llamada OAuth.
En 2010, Google ofreció a los pequeños editores de aplicaciones una forma de escribir servicios que utilizaran la información de la cuenta de Google en lugar de pedir a los usuarios que compartieran sus contraseñas de Google con terceros. En lugar de almacenar datos confidenciales de contraseñas y mantener la seguridad de las cuentas de usuario, un tercero podía utilizar el sistema de Google para pedir a los usuarios que se autenticaran y almacenar un token de acceso. El token de acceso almacenaba la autorización de la cuenta de Google y, a continuación, la aplicación externa utilizaba el token OAuth para acceder a un conjunto definido de datos de la cuenta de Google.
El protocolo OAuth ha pasado por varias iteraciones, con las últimas mejoras importantes en 2012. Varias otras grandes empresas tecnológicas ofrecen ahora integración OAuth para desarrolladores externos. Amazon, Netflix, PayPal, Microsoft, LinkedIn, Facebook y muchas otras permiten a los desarrolladores externos integrar los datos de sus cuentas de usuario en las aplicaciones utilizando OAuth.
¿Por qué se utiliza OAuth?
Antes de OAuth, cada servicio basado en la web tenía credenciales independientes para una cuenta de usuario. Los servicios no podían compartir datos a menos que ofrecieran una API en la que se pudieran transferir datos entre ambos. Incluso con una API, la transferencia de contraseñas entre servicios es una vulnerabilidad de seguridad, ya que expone los datos privados de varios servicios si se vulnera uno solo.
OAuth permite a los usuarios dar acceso a sus cuentas a aplicaciones externas para una amplia gama de funciones. Algunos ejemplos son el uso de los datos del calendario para facilitar la programación, el almacenamiento de los ajustes de la aplicación en la nube o incluso el análisis de sus listas de reproducción de música para obtener nuevas recomendaciones. Las contraseñas ya no son necesarias para la autorización, y los usuarios pueden revocar el acceso en cualquier momento. Los desarrolladores externos de aplicaciones almacenan un token de acceso para recuperar los datos autorizados, que debe almacenarse de forma segura, pero no expone las credenciales del usuario.
¿Cómo funciona OAuth?
En una transacción OAuth satisfactoria intervienen tres entidades:
- El usuario (la persona u organización que autoriza el acceso a sus datos)
- El proveedor de servicios de OAuth (es la aplicación o servicio que almacena los datos y credenciales del usuario)
- El consumidor (la aplicación que solicita el acceso a los datos del usuario)
OAuth utiliza un flujo de trabajo definido para garantizar la seguridad de los datos del usuario y simplificar las solicitudes para el consumidor. En primer lugar, la aplicación que solicita el acceso (consumidor) pide un token de acceso OAuth al proveedor del servicio. Si aún no ha iniciado sesión en el proveedor de servicios, se pide a los usuarios que lo hagan. A continuación, el proveedor de servicios enumera los tipos de datos a los que la aplicación del consumidor pretende acceder y pide al usuario que apruebe o deniegue el acceso. Si el usuario está de acuerdo, el proveedor de servicios envía entonces un token de acceso al consumidor, que lo almacena para futuras solicitudes de acceso. Una vez validado, el token de acceso se utiliza en todas las solicitudes de acceso a los datos del usuario (dentro del ámbito de los permisos concedidos por el usuario).
Los OAuth tokens de acceso caducan, por lo que los proveedores de servicios ofrecen a los desarrolladores una forma de actualizar los tokens de acceso para futuras solicitudes. El plazo de caducidad de un token de acceso lo establece el proveedor de servicios, por lo que su duración depende de los protocolos de seguridad del proveedor de servicios. El OAuth token de acceso debe almacenarse de forma segura porque puede ser utilizado por cualquiera para obtener datos del usuario y realizar funciones en su nombre.
Si el usuario decide revocar el acceso, puede hacerlo a través del proveedor de servicios. Una vez revocado el acceso, el consumidor deberá pedir al usuario que vuelva a autenticarse para obtener cualquier dato almacenado en la aplicación del proveedor de servicios. Si el consumidor sufre una vulneración de datos en la que se revelan los tokens de acceso, el proveedor de servicios podría invalidar proactivamente todos los tokens de acceso para proteger los datos del usuario.
OAuth vs. OpenID
Cuando los consumidores utilizan OAuth, el proveedor de servicios proporciona acceso autorizado a los datos de un usuario solamente después de que dé su consentimiento. OAuth es una forma de compartir datos utilizando un token de autorización proporcionado por el consumidor después de que el usuario verifique sus credenciales. OpenID es distinto de OAuth, pero ambos se utilizan juntos.
El inicio de sesión único (SSO) es una estrategia de seguridad común que utiliza un proveedor para autenticar a los usuarios en varios servicios. OpenID es uno de los protocolos SSO más antiguos, introducido en 2005 para autenticar en LiveJournal. Ha pasado por algunas actualizaciones, pero se consideró demasiado difícil de implementar en comparación con otros métodos de la época, principalmente Facebook Connect. Como Facebook era una marca muy conocida, la mayoría de los desarrolladores se pasaron a Facebook Connect para que los usuarios se sintieran más cómodos autenticándose en sus aplicaciones.
En 2014, OpenID rediseñó su código y posteriormente se incorporó a OAuth. Ahora, OAuth utiliza OpenID como capa de autenticación y OAuth se ocupa de la capa de autorización. El proceso es fluido para el usuario, pero los consumidores pueden integrar más fácilmente OAuth tanto para autenticar a los usuarios como para obtener acceso a los datos de sus cuentas.
OAuth vs. SAML
Un producto anterior similar a OAuth es el Lenguaje de Marcado para Confirmaciones de Seguridad (o SAML, del inglés “Security Assertion Markup Language”), que está basado en XML. La principal diferencia entre SAML y OAuth es que SAML realiza tanto la autenticación como la autorización. OAuth utiliza OpenID como capa de autenticación, pero no gestiona la autenticación por sí mismo. Las aplicaciones que utilizan SAML no necesitan ningún otro servicio para proporcionar autenticación.
Otra diferencia entre los dos protocolos es el lenguaje utilizado para trasladar datos entre servicios. SAML utiliza XML; OAuth utiliza JSON, el formato preferido para las transferencias de datos. La mayoría de los servicios de datos trabajan principalmente con JSON, lo que hace que OAuth sea más fácil de integrar para la mayoría de las empresas.
OAuth 1.0 vs. OAuth 2.0
Como cualquier otro protocolo, OAuth ha evolucionado y mejorado con el tiempo. OAuth 2.0 ha sustituido a OAuth 1.0 (que ya no es seguro), por lo que la mayoría de los proveedores de servicios sólo permiten el acceso con OAuth 2.0. OAuth 1.0 es más fácil de usar y presenta un flujo de trabajo más sencillo en algunos aspectos. Pero ya no se considera una forma segura de trabajar con cuentas de usuario.
OAuth 2.0 añadió dos pasos al flujo de trabajo de autorización. Es compatible con HTTPS y secretos firmados, por lo que ya no es necesario cifrar los tokens en los puntos de contacto (dispositivos de usuario). HTTPS cifra los tokens de acceso en tránsito, aunque algunos servicios que almacenan información de identificación personal (PII) u otros datos delicados siguen cifrando los datos en reposo. Una crítica a OAuth 2.0 es que permite la transferencia de datos a través de canales no cifrados, por lo que los desarrolladores son responsables de mantener el cifrado TLS/SSL a través de los canales.
Ejemplos de OAuth 2.0
Para que un desarrollador pueda beneficiarse de OAuth 2.0, el proveedor de servicios debe tenerlo implementado en su sistema. Diversos grandes sitios de redes sociales utilizan OAuth 2.0 para incorporar la integración de su plataforma con otras aplicaciones. Es una ventaja de marketing que ayuda a los propietarios de plataformas a conseguir seguidores para sus productos.
Desde que Google lanzó por primera vez OAuth 2.0, muchas aplicaciones trabajan con él como proveedor de SSO y como servicio que proporciona información básica sobre el usuario. En un flujo de trabajo OAuth 2.0 sencillo, el consumidor ofrece un enlace a “Iniciar sesión con Google” como opción para crear una cuenta. Si el usuario ya está autenticado, Google muestra una lista de recursos y datos a los que el consumidor tendría acceso si el usuario está de acuerdo.
El usuario puede permitir o rechazar la solicitud de autorización del consumidor. Si el usuario la rechaza, el consumidor no podrá acceder a los datos del usuario. Si el usuario permite la solicitud de datos, el proveedor de servicios entrega al consumidor un token de acceso. El token de acceso proporciona autorización sólo para los datos enumerados en la solicitud original. En la mayoría de las principales plataformas, la aplicación del consumidor debe ser verificada previamente por el proveedor de servicios antes de acceder a determinados datos. Normalmente, el consumidor esboza qué datos necesita para funcionar y cómo se utilizarán esos datos. El proveedor de servicios puede permitir o rechazar la solicitud de forma preventiva.
OAuth también se utiliza para integrar una plataforma en otro servicio. Supongamos que tiene una aplicación que funciona directamente con el producto de Google, como Gmail. Para leer directamente los correos electrónicos de sus usuarios, necesita el permiso del usuario. Google utiliza OAuth para permitir que su aplicación interactúe con la cuenta de Gmail del usuario. Para utilizar el servicio Gmail de Google en su aplicación, usted especifica los datos necesarios para que la aplicación funcione; a continuación, los usuarios deben autorizar a la aplicación a acceder a ellos.
¿Es seguro el OAuth?
OAuth es una forma de acceso seguro si se implementa correctamente. El proveedor de servicios debe asegurarse de que el consumidor tiene autorización para los datos; el consumidor debe utilizar TLS/SSL para establecer una conexión segura y transferir los datos de forma cifrada. El proveedor de servicios puede garantizar que los datos se transmiten de forma segura exigiendo a los consumidores que utilicen conexiones cifradas y rechazando cualquier canal no cifrado.
Los riesgos del OAuth
Aunque es más seguro que compartir credenciales, OAuth no está exento de riesgos. He aquí algunas trampas de seguridad con las que las organizaciones deben tener cuidado cuando permiten a los usuarios conectar aplicaciones externas a sus cuentas utilizando OAuth.
Phishing
La amenaza del phishing es una de las principales preocupaciones con OAuth. Los atacantes suelen utilizar enlaces a páginas web con solicitudes para que los usuarios introduzcan credenciales para autenticarse en sus cuentas. La página parece una página oficial similar a un servicio que utiliza OAuth. Pero en lugar de autenticarse en un servicio oficial, el usuario está introduciendo sus credenciales en una página web de phishing de un atacante. Los usuarios deben comprobar la dirección que aparece en la ventana emergente del navegador de autenticación para asegurarse de que el sitio es legítimo.
En una campaña de phishing que descubrimos, los atacantes obtuvieron acceso a las credenciales de usuario de Microsoft modificando los parámetros de la cadena de consulta de la URL para redirigir a los usuarios a un sitio web de robo de credenciales.
La página de phishing mostraba un mensaje de permiso de Microsoft falsificado que resultaba familiar a la mayoría de los usuarios. La página pide a los usuarios que inicien sesión en su cuenta de Microsoft, pero en lugar de autenticar a los usuarios, proporciona a los atacantes las credenciales de inicio de sesión de la cuenta de Microsoft. Estas credenciales pueden utilizarse para hacerse con el control de las cuentas de Microsoft, obtener datos de los usuarios o secuestrar cuentas de otros servicios en los que los usuarios hayan reutilizado esas credenciales.
Permisos demasiado amplios
Cuando los usuarios instalan y autorizan aplicaciones a través de OAuth, a menudo hacen clic en aceptar sin revisar detenidamente el alcance de los permisos. Cualquier app que tenga permisos de acceso amplios es un riesgo potencial para la seguridad de su organización.
Las aplicaciones externas pueden ser explotadas fácilmente. Los atacantes pueden utilizar el acceso OAuth para comprometer y secuestrar cuentas en la nube. Hasta que se revoque explícitamente el token OAuth, el atacante tiene acceso persistente a la cuenta y los datos del usuario, incluso si éste cambia la contraseña de la cuenta en la nube o utiliza la autenticación de dos factores (2FA).
Nuestras investigaciones han determinado que muchas aplicaciones OAuth para Office 365 tienen altos niveles de permisos. He aquí algunos de nuestros hallazgos:
- El 30% de los inquilinos tienen aplicaciones como MailMerge365 con el permiso “enviar correo en nombre de otros”.
- El 30% de los inquilinos tienen aplicaciones como TypeApp con el permiso “gestionar la configuración de exchange”.
- El 70% de los inquilinos tienen de media nueve apps que utilizan el permiso “enviar correo como usuario” (como Task in A Box).
- Los inquilinos de Microsoft 365 tienen de media 34 apps que utilizan el permiso “acceder a los datos del usuario en cualquier momento” (como es el caso de OneSync).
- Los inquilinos de Google Workspace con apps externas en la categoría “juegos” tienen una media de 10 juegos.
Aplicaciones OAuth malintencionadas
Algunas aplicaciones y sus solicitudes de permiso OAuth son abiertamente malintencionadas. Por ejemplo, nuestros investigadores han estado rastreando una campaña de ataque denominada OiVaVoii que publica aplicaciones malintencionadas bajo la apariencia de editores de aplicaciones de confianza. Funciona de la siguiente manera:
- En primer lugar, el atacante secuestra la cuenta del editor legítimo de la aplicación.
- Haciéndose pasar por el editor de confianza, el atacante crea entonces una aplicación malintencionada y envía solicitudes de autorización a los usuarios, muchos de ellos ejecutivos de alto nivel, a través del correo electrónico.
- Los usuarios desprevenidos autorizan la aplicación, creyendo que procede del editor de confianza.
- Con los permisos OAuth concedidos, el atacante toma el control de la cuenta del usuario.
En esta campaña, hemos detectado secuestros de cuentas pertenecientes a CEO, gerentes generales, antiguos miembros del consejo de administración y presidentes. Normalmente, la toma de control es el resultado de aplicaciones OAuth malintencionadas que roban tokens o credenciales OAuth.
La identidad aparentemente benigna de la organización editora fue una ventaja sustancial, que atrajo a varias víctimas desprevenidas para que autorizaran las apps malintencionadas. En la mayoría de los casos se trataba de accesos a buzones de correo (lectura y escritura), lo que les permitía:
- Enviar correo electrónico malintencionado interno y externo
- Robar información valiosa
- Crear reglas de buzón para enviar datos al atacante y seguir obteniendo el correo electrónico de los usuarios tras el ataque
Figura 1: Captura de pantalla de la solicitud de permiso OAuth de la aplicación malintencionada.
Abuso de aplicaciones OAuth legítimas
Contactually es una aplicación legítima en la nube que ayuda a los profesionales inmobiliarios a gestionar clientes y ventas. Pero en las manos equivocadas, sus potentes funciones permiten a los atacantes moverse lateralmente con facilidad dentro del entorno de la víctima y mantener el acceso.
Detectamos una campaña que comenzó con phishing basado en correo electrónico para comprometer a usuarios dentro de las organizaciones seleccionadas. Utilizando las cuentas comprometidas, los atacantes autorizaron la aplicación Contactually y configuraron reglas de buzón que redirigían o eliminaban el correo electrónico. Es probable que las reglas estuvieran diseñadas para redirigir correo valioso a cuentas externas y eliminar pruebas del ataque.
Contactually es un editor legítimo. La aplicación tiene algunos ámbitos de permisos amplios, como el acceso total a los contactos del usuario y el acceso de lectura y escritura a su correo electrónico. Pero estos son similares a los utilizados por cualquier cliente de correo electrónico y están bien dentro de los límites de las funciones anunciadas de la app.
Aun así, si los atacantes han comprometido la cuenta y autorizan la app dentro de su entorno, como hicieron en la campaña que detectamos, pueden explotar esas funciones para causar daños persistentes.
Cómo proteger su organización frente a las amenazas avanzadas para la nube actuales
Las amenazas para la nube no son nuevas, pero la forma en la que atacan a las organizaciones actualmente progresa a un ritmo alarmante.
Seguridad en la nube
Conozca más sobre cloud security o seguridad en la nube, incluyendo los principales riesgos y consejos de seguridad de Proofpoint.
Ebook: Proteja su despliegue de Microsoft 365
La adopción generalizada de la nube por parte de las empresas hace fundamental proteger su despliegue de Microsoft 365. Este libro electrónico ofrece 10 razones por las que las organizaciones optan por una ciberseguridad centrada en las personas.