OAuth: inicio de sesión único en varias plataformas

En nuestro día a día, visitamos muchos sitios web y utilizamos diferentes programas y aplicaciones móviles para hacer que nuestra vida personal y profesional sea más sencilla y agradable. Al existir tal cantidad de herramientas a nuestra disposición, cada vez es más normal utilizar el contenido de una aplicación web (como Instagram) en otro sitio web (como Facebook). En resumen, el contenido se utiliza en varias plataformas al mismo tiempo. Sin embargo, para que estos procesos puedan llevarse a cabo, es necesario ceder muchos datos personales y, en este punto, surge la cuestión relativa a la seguridad de la privacidad. El protocolo de autenticación OAuth ha sido diseñado precisamente para reducir los riesgos asociados al uso no autorizado de nuestros datos. La pregunta es: ¿está realmente a la altura de su cometido?

OAuth es la abreviatura de “open authorization” y es un protocolo estándar abierto que permite la autenticación segura de API. El térmico técnico API (siglas de application programming interface) hace referencia en este contexto a una interfaz que sirve para transmitir datos entre diferentes aplicaciones, interfaces de usuario y páginas web. Es necesario que la API autorice estas transferencias de datos porque, en caso contrario, nos estaríamos exponiendo al riesgo de que un tercero los interceptara sin autorización e hiciera un uso incorrecto de los mismos en su propio beneficio.

Por ejemplo, supongamos que un usuario va a utilizar una app para hacer una publicación en Facebook en su nombre (lo que significa que va a acceder a la API de Facebook). Será necesario que dicha app cuente con el permiso del usuario. Del mismo modo, cualquier aplicación necesitará haber sido autorizada por el usuario para poder completar su perfil mediante la información de otro servicio. OAuth es una herramienta que nos permite otorgar dicha autorización sin tener que comunicar a la aplicación el nombre de usuario ni la contraseña. En resumen, el usuario mantiene un control absoluto sobre sus datos.

Por su parte, proveedores como Google, Twitter y Facebook pueden utilizar OAuth para que sus productos y servicios sean más flexibles y, al mismo tiempo, más seguros, por ejemplo, mediante soluciones single sign on. Amazon y Microsoft también se han unido al círculo de grandes empresas que confían en OAuth como estándar de delegación de acceso.

OAuth2 (también conocida como OAuth 2.0) es una versión no retrocompatible que se publicó en octubre de 2012 y supuso una completa revisión de OAuth. Actualmente, ha acabado reemplazando en gran medida a la anterior versión. Por ejemplo, la Graph API de Facebook solo soporta el nuevo protocolo como estándar de autorización, que basa su funcionamiento en la capa de autenticación OpenID Connect (OIDC).

En principio, OAuth2 tiene la misma función que la versión anterior: aportar al usuario un equilibrio entre usabilidad y seguridad mediante la autorización de API. En esta nueva versión se subsanaron numerosas deficiencias presentes en el protocolo original que complicaban la programación e implementación en los sistemas de Facebook, Twitter y otros operadores de API a medida que estos se volvían más complejos con el paso del tiempo.

Aparte de la terminología, completamente nueva, la característica más importante que distingue a OAuth2 de su versión anterior es que ya no utiliza firmas criptográficas para las comunicaciones máquina a máquina en el flujo del protocolo. De esta forma, se simplifica mucho su aplicación y extensión. Eso sí, la medida también implica que el nuevo protocolo sea, desde un punto de vista técnico, menos seguro, un argumento muy utilizado para poner OAuth2 en entredicho.

La versión Open Authorization 2.0 también incorpora tipos de permisos más diferenciados (grant types) y aumenta el rendimiento general del protocolo. Para implementar estas mejoras, los desarrolladores de OAuth2 decidieron dejar de solicitar los datos de acceso al usuario (resource owner) cada vez que se establecía una comunicación y, por el contrario, solicitar exclusivamente una autorización inicial a la aplicación pertinente (cliente). Otra innovación destacable radica en los access tokens, con tiempos de validez más cortos, lo que facilita al servicio (resource server) revocar autorizaciones. Además, los usuarios pueden decidir ellos mismos qué autorizaciones concretas (scope) quieren conceder a una aplicación.

Cuando se habla, en concreto, del concepto de single sign on (SSO o autenticación única), se suele escuchar el nombre de OAuth junto con el de OpenID y SAML. Aunque los tres tienen que ver con la verificación segura de identidades de usuario, existen diferencias importantes entre ellos.

OpenID (abreviatura de “open identification”) es un protocolo abierto: cuando un usuario crea una cuenta en OpenID, puede iniciar sesión en otros servicios y aplicaciones que soporten OpenID a través de un token. Un buen ejemplo lo encontramos en el botón “Iniciar sesión con Google”, que aparece en numerosos sitios web y permite llevar a cabo el procedimiento de autenticación única utilizando la cuenta de Google del usuario.

Si hablamos con total propiedad, podemos decir que OpenID, en comparación con OAuth, no es un estándar de autorización sino un estándar de autenticación. De todas formas, los dos protocolos guardan desde 2014 una estrecha relación: OAuth 2.0 es la base sobre la que se ha construido la nueva versión de OpenID, llamada OpenID Connect (OIDC). OAuth2 permite que diferentes tipos de aplicaciones (clientes) comprueben la identidad del usuario mediante la autenticación que efectúa un servidor de autorización y, de paso, obtengan información básica sobre el usuario. A cambio, se añaden al protocolo todas las funciones necesarias para llevar a cabo el inicio de sesión y el single sign on. Asimismo, OpenID Connect puede ampliarse con funciones opcionales como la gestión de sesiones y el encriptado de las credenciales personales.

Security Assertion Markup Language (abreviado como SAML) es un estándar abierto basado en XML que, en cierto sentido, combina las propiedades de los dos estándares comentados en el punto anterior. Se trata, por lo tanto, de un estándar de autenticación y de autorización. SAML tiene una funcionalidad parecida a la de OpenID y también puede utilizarse para llevar a cabo procesos de single sign on.

Si queremos entender cómo funciona OAuth2, resulta muy útil tener una visión general de los roles y flujos de autorización definidos en el protocolo.

En OAuth2 existen cuatro roles:

• Resource owner (user o usuario): entidad que concede a un cliente acceso a sus datos protegidos (recursos).
• Resource server (servicio): un servidor en el que se almacenan los datos protegidos del resource owner.
• Cliente (third-party o tercero): una aplicación de escritorio, web o móvil que desea acceder a los datos protegidos del resource owner.
• Authorization server: un servidor que autentica al resource owner y emite un access token temporal para un ámbito (scope) definido por el propietario del recurso. En la práctica, el authorization server y el resource server se utilizan a menudo juntos y se denominan también OAuth server.

Este estándar diferencia cuatro procesos o flujos de autorización predefinidos (grant types), que se utilizan en varias aplicaciones:

• Código de autorización: el cliente solicita al resource owner que inicie sesión en el authorization server. El resource owner es, en ese momento, redirigido al cliente junto con un código de autorización. Ese código sirve para que el authorization server emita un access token para el cliente.
• Autorización implícita (implicit authorization): este proceso de autorización se parece bastante a la autorización mediante código que acabamos de comentar, pero es menos complejo porque el authorization server emite el access token directamente.
• Credenciales de contraseña de propietario del recurso (resource owner password credentials): en este caso, el resource owner confía sus datos de acceso directamente al cliente, algo que es directamente contrario al principio básico de OAuth, pero que implica menos esfuerzo para el resource owner.
• Credenciales de cliente (client credentials): este proceso de autorización es especialmente sencillo y se utiliza cuando un cliente quiere acceder a datos que no tienen propietario o que no requieren autorización.

En caso de que un cliente necesite obtener acceso a los datos protegidos del resource owner en el futuro, podrá utilizar un refresh token, que tiene una duración limitada pero dura más que el access token, para solicitar un nuevo access token al authorization server. El resource owner no tiene que dar una nueva autorización.

Las redes sociales Pinterest y Facebook nos van a servir como casos prácticos para explicar el flujo de protocolo en OAuth2. Pinterest nos da la opción de importar los contactos desde la lista de amigos de Facebook. Para hacerlo, Pinterest necesita tener acceso a la cuenta y a la información que esta tiene almacenada. Por razones de seguridad, como es obvio, no resulta recomendable compartir el nombre de usuario y la contraseña de Facebook con Pinterest. Ten en cuenta que, si esto ocurriera, Pinterest tendría un acceso ilimitado a todos los datos y funciones de la cuenta de Facebook. No obstante, si queremos que Pinterest acceda a los datos concretos que necesita de Facebook, podemos utilizar OAuth2:

1. Lo primero es iniciar sesión con tu cuenta de Pinterest y acceder a la configuración de tu perfil de usuario.
2. Luego, hay que ir al menú “Redes sociales” y mover el control situado junto a Facebook a “Sí”.
3. Cuando te pregunte, permite a Pinterest acceder a tu cuenta de Facebook para validar la app de Pinterest. Esta acción se considera una aprobación de autorización.
4. Pinterest solicita un access token al authorization server de Facebook y luego lo utiliza para acceder a los datos protegidos del resource server.
5. Los amigos de Facebook que han sido importados aparecerán a partir de ahora también en tu cuenta de Pinterest.

Un sistema como OAuth, a pesar de haber sido diseñado específicamente para proteger los datos personales, no puede garantizar al cien por cien su fiabilidad, algo que quedó demostrado en abril de 2009 cuando se descubrió una laguna de seguridad en el proceso de autenticación del protocolo. Al igual que ocurre con otros sistemas parecidos, el phishing es un riesgo constante: entre abril y mayo de 2017, un millón de usuarios de Gmail fueron víctimas de un ataque de phishing mediante OAuth. Mediante un correo electrónico fraudulento, se les pidió que autorizaran una interfaz falsa para permitir que una supuesta aplicación llamada “Google Apps” accediera a la información de su cuenta.

Cabría esperar que, con el desarrollo de OAuth2, no solo se hubiera conseguido facilitar la implementación del protocolo, que es cada vez más complejo, sino también aumentar la seguridad. En octubre de 2012, los esfuerzos puestos en este nuevo proyecto por fin dieron resultado y se llegó a una solución definitiva que, sin embargo, no fue aprobada por los desarrolladores que habían participado en la creación del estándar OAuth original. De hecho, el propio Eran Hammer-Lahav, el director de desarrollo de OAuth2 y la única persona que también había participado en el anterior OAuth, decidió distanciarse del nuevo proyecto cuando solo faltaban tres meses para su lanzamiento. En un artículo publicado en su blog hueniverse.com el 26 de julio de 2012, explicó los motivos de esta decisión y se refirió a la versión OAuth 2.0 como “el camino hacia el infierno” ya en el título.

¿Qué había pasado? Según Hammer-Lahav, el desarrollo del nuevo protocolo estuvo marcado por las constantes discusiones entre los desarrolladores y las empresas involucradas (entre las que podemos citar a Yahoo!, Google, Twitter y Deutsche Bank). Afirma que, cuando surgían cuestiones controvertidas, muchas veces eran simplemente ignoradas en favor de los intereses económicos. En consecuencia, según Hammer-Lahav, OAuth2 no podía seguir considerándose un protocolo, ya que, de un estándar claramente definido, había pasado a ser un mero framework con gran capacidad para adaptarse y ampliarse. Es decir, OAuth2 había perdido una de sus principales características: la interoperabilidad. Al contrario, las diferentes implementaciones de OAuth2 ya no eran necesariamente compatibles entre sí.

Otra cosa que Hammer-Lahav lamentaba era el hecho de que se decidiera establecer una implementación más sencilla (un ejemplo es que ya no necesita firmas), pues esto se traduce en una falta de seguridad. Para programar una aplicación segura que soportara Oauth2, habría que contar con desarrolladores que tuvieran mucha experiencia. Para él resultaba mucho más probable, en cambio, que en el futuro la red se llenara de aplicaciones poco seguras. Según Hammer-Lahav, los errores de implementación no iban a poder evitarse porque las especificaciones eran excesivamente complejas e incompletas.

Se ha demostrado que los temores de Hammer-Lahav eran fundados, al menos en parte: en 2016, un grupo de investigación de la Universidad de Trier, en Alemania, estudió por primera vez la seguridad de OAuth2 y descubrió dos vulnerabilidades. Una de ellas permitía que se produjeran ataques de intermediario (man-in-the-middle). No obstante, en términos generales, hay que decir que los investigadores consideraron que el protocolo era relativamente seguro, siempre que se implementara correctamente. Entretanto, el equipo de OAuth2 asegura haber puesto ya remedio a las vulnerabilidades. En cualquier caso, el informe del estudio abrió el camino para que muchos expertos en TI analizaran el uso seguro de OAuth 2.0 de forma más detallada.