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.