OAuth: inicio de sesión único en varias pla­ta­fo­r­mas

En nuestro día a día, visitamos muchos sitios web y uti­li­za­mos di­fe­re­n­tes programas y apli­ca­cio­nes móviles para hacer que nuestra vida personal y pro­fe­sio­nal sea más sencilla y agradable. Al existir tal cantidad de he­rra­mie­n­tas a nuestra di­s­po­si­ción, cada vez es más normal utilizar el contenido de una apli­ca­ción web (como Instagram) en otro sitio web (como Facebook). En resumen, el contenido se utiliza en varias pla­ta­fo­r­mas al mismo tiempo. Sin embargo, para que estos procesos puedan llevarse a cabo, es necesario ceder muchos datos pe­r­so­na­les y, en este punto, surge la cuestión relativa a la seguridad de la pri­va­ci­dad. El protocolo de au­te­n­ti­ca­ción OAuth ha sido diseñado pre­ci­sa­me­n­te para reducir los riesgos asociados al uso no au­to­ri­za­do de nuestros datos. La pregunta es: ¿está realmente a la altura de su cometido?

OAuth es la abre­via­tu­ra de “open au­tho­ri­za­tion” y es un protocolo estándar abierto que permite la au­te­n­ti­ca­ción segura de API. El térmico técnico API (siglas de ap­pli­ca­tion pro­gra­m­mi­ng interface) hace re­fe­re­n­cia en este contexto a una interfaz que sirve para tra­n­s­mi­tir datos entre di­fe­re­n­tes apli­ca­cio­nes, in­te­r­fa­ces de usuario y páginas web. Es necesario que la API autorice estas tra­n­s­fe­re­n­cias de datos porque, en caso contrario, nos es­ta­ría­mos ex­po­nie­n­do al riesgo de que un tercero los in­te­r­ce­p­ta­ra sin au­to­ri­za­ción e hiciera un uso in­co­rre­c­to de los mismos en su propio beneficio.

Por ejemplo, su­po­n­ga­mos que un usuario va a utilizar una app para hacer una pu­bli­ca­ció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 apli­ca­ción ne­ce­si­ta­rá haber sido au­to­ri­za­da por el usuario para poder completar su perfil mediante la in­fo­r­ma­ción de otro servicio. OAuth es una he­rra­mie­n­ta que nos permite otorgar dicha au­to­ri­za­ción sin tener que comunicar a la apli­ca­ción el nombre de usuario ni la co­n­tra­se­ña. En resumen, el usuario mantiene un control absoluto sobre sus datos.

Por su parte, pro­vee­do­res 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 so­lu­cio­nes 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 de­le­ga­ción de acceso.

OAuth2 (también conocida como OAuth 2.0) es una versión no re­tro­co­m­pa­ti­ble que se publicó en octubre de 2012 y supuso una completa revisión de OAuth. Ac­tua­l­me­n­te, ha acabado re­em­pla­za­n­do en gran medida a la anterior versión. Por ejemplo, la Graph API de Facebook solo soporta el nuevo protocolo como estándar de au­to­ri­za­ción, que basa su fu­n­cio­na­mie­n­to en la capa de au­te­n­ti­ca­ción OpenID Connect (OIDC).

En principio, OAuth2 tiene la misma función que la versión anterior: aportar al usuario un equi­li­brio entre usa­bi­li­dad y seguridad mediante la au­to­ri­za­ción de API. En esta nueva versión se su­b­sa­na­ron numerosas de­fi­cie­n­cias presentes en el protocolo original que co­m­pli­ca­ban la pro­gra­ma­ción e im­ple­me­n­ta­ción en los sistemas de Facebook, Twitter y otros ope­ra­do­res de API a medida que estos se volvían más complejos con el paso del tiempo.

Aparte de la te­r­mi­no­lo­gía, co­m­ple­ta­me­n­te nueva, la ca­ra­c­te­rí­s­ti­ca más im­po­r­ta­n­te que distingue a OAuth2 de su versión anterior es que ya no utiliza firmas cri­p­to­grá­fi­cas para las co­mu­ni­ca­cio­nes máquina a máquina en el flujo del protocolo. De esta forma, se si­m­pli­fi­ca mucho su apli­ca­ció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 en­tre­di­cho.

La versión Open Au­tho­ri­za­tion 2.0 también incorpora tipos de permisos más di­fe­re­n­cia­dos (grant types) y aumenta el re­n­di­mie­n­to general del protocolo. Para im­ple­me­n­tar estas mejoras, los de­sa­rro­lla­do­res de OAuth2 de­ci­die­ron dejar de solicitar los datos de acceso al usuario (resource owner) cada vez que se es­ta­ble­cía una co­mu­ni­ca­ción y, por el contrario, solicitar ex­clu­si­va­me­n­te una au­to­ri­za­ción inicial a la apli­ca­ción pe­r­ti­ne­n­te (cliente). Otra in­no­va­ción de­s­ta­ca­ble radica en los access tokens, con tiempos de validez más cortos, lo que facilita al servicio (resource server) revocar au­to­ri­za­cio­nes. Además, los usuarios pueden decidir ellos mismos qué au­to­ri­za­cio­nes concretas (scope) quieren conceder a una apli­ca­ción.

Cuando se habla, en concreto, del concepto de single sign on (SSO o au­te­n­ti­ca­ción única), se suele escuchar el nombre de OAuth junto con el de OpenID y SAML. Aunque los tres tienen que ver con la ve­ri­fi­ca­ción segura de ide­n­ti­da­des de usuario, existen di­fe­re­n­cias im­po­r­ta­n­tes entre ellos.

OpenID (abre­via­tu­ra de “open ide­n­ti­fi­ca­tion”) es un protocolo abierto: cuando un usuario crea una cuenta en OpenID, puede iniciar sesión en otros servicios y apli­ca­cio­nes que soporten OpenID a través de un token. Un buen ejemplo lo en­co­n­tra­mos en el botón “Iniciar sesión con Google”, que aparece en numerosos sitios web y permite llevar a cabo el pro­ce­di­mie­n­to de au­te­n­ti­ca­ción única uti­li­za­n­do la cuenta de Google del usuario.

Si hablamos con total propiedad, podemos decir que OpenID, en co­m­pa­ra­ción con OAuth, no es un estándar de au­to­ri­za­ción sino un estándar de au­te­n­ti­ca­ción. De todas formas, los dos pro­to­co­los guardan desde 2014 una estrecha relación: OAuth 2.0 es la base sobre la que se ha co­n­s­trui­do la nueva versión de OpenID, llamada OpenID Connect (OIDC). OAuth2 permite que di­fe­re­n­tes tipos de apli­ca­cio­nes (clientes) co­m­prue­ben la identidad del usuario mediante la au­te­n­ti­ca­ción que efectúa un servidor de au­to­ri­za­ción y, de paso, obtengan in­fo­r­ma­ción básica sobre el usuario. A cambio, se añaden al protocolo todas las funciones ne­ce­sa­rias para llevar a cabo el inicio de sesión y el single sign on. Asimismo, OpenID Connect puede ampliarse con funciones op­cio­na­les como la gestión de sesiones y el en­cri­p­ta­do de las cre­de­n­cia­les pe­r­so­na­les.

Security Assertion Markup Language (abreviado como SAML) es un estándar abierto basado en XML que, en cierto sentido, combina las pro­pie­da­des de los dos es­tá­n­da­res co­me­n­ta­dos en el punto anterior. Se trata, por lo tanto, de un estándar de au­te­n­ti­ca­ción y de au­to­ri­za­ción. SAML tiene una fu­n­cio­na­li­dad parecida a la de OpenID y también puede uti­li­zar­se 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 au­to­ri­za­ció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 pro­te­gi­dos (recursos).
• Resource server (servicio): un servidor en el que se almacenan los datos pro­te­gi­dos del resource owner.
• Cliente (third-party o tercero): una apli­ca­ción de es­cri­to­rio, web o móvil que desea acceder a los datos pro­te­gi­dos del resource owner.
• Au­tho­ri­za­tion server: un servidor que autentica al resource owner y emite un access token temporal para un ámbito (scope) definido por el pro­pie­ta­rio del recurso. En la práctica, el au­tho­ri­za­tion server y el resource server se utilizan a menudo juntos y se denominan también OAuth server.

Este estándar di­fe­re­n­cia cuatro procesos o flujos de au­to­ri­za­ción pre­de­fi­ni­dos (grant types), que se utilizan en varias apli­ca­cio­nes:

• Código de au­to­ri­za­ción: el cliente solicita al resource owner que inicie sesión en el au­tho­ri­za­tion server. El resource owner es, en ese momento, re­di­ri­gi­do al cliente junto con un código de au­to­ri­za­ción. Ese código sirve para que el au­tho­ri­za­tion server emita un access token para el cliente.
• Au­to­ri­za­ción implícita (implicit au­tho­ri­za­tion): este proceso de au­to­ri­za­ción se parece bastante a la au­to­ri­za­ción mediante código que acabamos de comentar, pero es menos complejo porque el au­tho­ri­za­tion server emite el access token di­re­c­ta­me­n­te.
• Cre­de­n­cia­les de co­n­tra­se­ña de pro­pie­ta­rio del recurso (resource owner password cre­de­n­tia­ls): en este caso, el resource owner confía sus datos de acceso di­re­c­ta­me­n­te al cliente, algo que es di­re­c­ta­me­n­te contrario al principio básico de OAuth, pero que implica menos esfuerzo para el resource owner.
• Cre­de­n­cia­les de cliente (client cre­de­n­tia­ls): este proceso de au­to­ri­za­ción es es­pe­cia­l­me­n­te sencillo y se utiliza cuando un cliente quiere acceder a datos que no tienen pro­pie­ta­rio o que no requieren au­to­ri­za­ción.

En caso de que un cliente necesite obtener acceso a los datos pro­te­gi­dos 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 au­tho­ri­za­tion server. El resource owner no tiene que dar una nueva au­to­ri­za­ció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 in­fo­r­ma­ción que esta tiene al­ma­ce­na­da. Por razones de seguridad, como es obvio, no resulta re­co­me­n­da­ble compartir el nombre de usuario y la co­n­tra­se­ñ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 co­n­fi­gu­ra­ció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 apro­ba­ción de au­to­ri­za­ción.
4. Pinterest solicita un access token al au­tho­ri­za­tion server de Facebook y luego lo utiliza para acceder a los datos pro­te­gi­dos del resource server.
5. Los amigos de Facebook que han sido im­po­r­ta­dos apa­re­ce­rán a partir de ahora también en tu cuenta de Pinterest.

Un sistema como OAuth, a pesar de haber sido diseñado es­pe­cí­fi­ca­me­n­te para proteger los datos pe­r­so­na­les, no puede ga­ra­n­ti­zar al cien por cien su fia­bi­li­dad, algo que quedó de­mo­s­tra­do en abril de 2009 cuando se descubrió una laguna de seguridad en el proceso de au­te­n­ti­ca­ció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 ele­c­tró­ni­co frau­du­le­n­to, se les pidió que au­to­ri­za­ran una interfaz falsa para permitir que una supuesta apli­ca­ción llamada “Google Apps” accediera a la in­fo­r­ma­ción de su cuenta.

Cabría esperar que, con el de­sa­rro­llo de OAuth2, no solo se hubiera co­n­se­gui­do facilitar la im­ple­me­n­ta­ció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 de­fi­ni­ti­va que, sin embargo, no fue aprobada por los de­sa­rro­lla­do­res que habían pa­r­ti­ci­pa­do en la creación del estándar OAuth original. De hecho, el propio Eran Hammer-Lahav, el director de de­sa­rro­llo de OAuth2 y la única persona que también había pa­r­ti­ci­pa­do en el anterior OAuth, decidió di­s­ta­n­ciar­se del nuevo proyecto cuando solo faltaban tres meses para su la­n­za­mie­n­to. En un artículo publicado en su blog hue­ni­ve­r­se.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 de­sa­rro­llo del nuevo protocolo estuvo marcado por las co­n­s­ta­n­tes di­s­cu­sio­nes entre los de­sa­rro­lla­do­res y las empresas in­vo­lu­cra­das (entre las que podemos citar a Yahoo!, Google, Twitter y Deutsche Bank). Afirma que, cuando surgían cue­s­tio­nes co­n­tro­ve­r­ti­das, muchas veces eran si­m­ple­me­n­te ignoradas en favor de los intereses eco­nó­mi­cos. En co­n­se­cue­n­cia, según Hammer-Lahav, OAuth2 no podía seguir co­n­si­de­rá­n­do­se un protocolo, ya que, de un estándar cla­ra­me­n­te 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 pri­n­ci­pa­les ca­ra­c­te­rí­s­ti­cas: la in­te­ro­pe­ra­bi­li­dad. Al contrario, las di­fe­re­n­tes im­ple­me­n­ta­cio­nes de OAuth2 ya no eran ne­ce­sa­ria­me­n­te co­m­pa­ti­bles entre sí.

Otra cosa que Hammer-Lahav lamentaba era el hecho de que se decidiera es­ta­ble­cer una im­ple­me­n­ta­ción más sencilla (un ejemplo es que ya no necesita firmas), pues esto se traduce en una falta de seguridad. Para programar una apli­ca­ción segura que soportara Oauth2, habría que contar con de­sa­rro­lla­do­res que tuvieran mucha ex­pe­rie­n­cia. Para él resultaba mucho más probable, en cambio, que en el futuro la red se llenara de apli­ca­cio­nes poco seguras. Según Hammer-Lahav, los errores de im­ple­me­n­ta­ción no iban a poder evitarse porque las es­pe­ci­fi­ca­cio­nes eran ex­ce­si­va­me­n­te complejas e in­co­m­ple­tas.

Se ha de­mo­s­tra­do que los temores de Hammer-Lahav eran fundados, al menos en parte: en 2016, un grupo de in­ve­s­ti­ga­ción de la Uni­ve­r­si­dad de Trier, en Alemania, estudió por primera vez la seguridad de OAuth2 y descubrió dos vu­l­ne­ra­bi­li­da­des. Una de ellas permitía que se pro­du­je­ran ataques de in­te­r­me­dia­rio (man-in-the-middle). No obstante, en términos generales, hay que decir que los in­ve­s­ti­ga­do­res co­n­si­de­ra­ron que el protocolo era re­la­ti­va­me­n­te seguro, siempre que se im­ple­me­n­ta­ra co­rre­c­ta­me­n­te. En­tre­ta­n­to, el equipo de OAuth2 asegura haber puesto ya remedio a las vu­l­ne­ra­bi­li­da­des. En cualquier caso, el informe del estudio abrió el camino para que muchos expertos en TI ana­li­za­ran el uso seguro de OAuth 2.0 de forma más detallada.