Desde el inicio de las redes distribuidas de computadoras personales, una de las cosas más difíciles de lograr ha sido proporcionar una experiencia de inicio de sesión único (SSO, por sus siglas en inglés) entre muchas computadoras, cada una de las cuales requiere de cuentas independientes de registro para acceder a sus servicios y contenidos.
Aunque no ha sido entendido por la Internet completa, ahora puede accederse a una vasta cantidad de páginas web no relacionadas usando un solo registro físico. Puede utilizar su contraseña, teléfono, certificado digital, identidad biométrica, solución SSO de autenticación de doble factor (2FA), o autenticación de factor múltiple (MFA) para registrarse en un lugar, y no tener que ingresar otra credencial de acceso en todo el día para acceder a otros. Debemos agradecerle a OAuth en gran parte por esto…
OAuth es un marco de trabajo o protocolo de autorización de estándar abierto que describe cómo los servicios y servidores no relacionados pueden permitir un acceso autenticado de manera segura a sus activos, sin compartir la credencial inicial única de registro. En el lenguaje de la autenticación, esto se conoce como delegación autorizada externa de usuario-agente.
OAuth, que recibió un fuerte respaldo por parte de Twitter, Google y otras compañías, se lanzó como estándar único en el 2010 denominado como RFC 5849, y se adoptó ampliamente en poco tiempo. En los dos años siguientes, pasó por una revisión substancial y la versión 2.0 de OAuth fue lanzada en el 2012, denominada como RFC 6749. Aunque la versión 2.0 fue muy criticada por muchas razones, que serán cubiertas más adelante, ganó incluso más popularidad. Hoy en día, puede añadir a Amazon, Facebook, Instagram, LinkedIn, Microsoft, Netflix, PayPal y una lista de otros nombres reconocidos de Internet como organizaciones que la han adoptado.
El ejemplo más simple de OAuth es cuando se registra en una página web, y ésta le ofrece una o más oportunidades de registrarse usando el registro de otra página web/servicio. Después le da clic al botón de enlace a otra página web, la otra página web le da autenticación, y la página web a la que se estaba conectando originalmente le registra en ella misma después de usar el permiso obtenido de la segunda página web.
Otro ejemplo común de un contexto OAuth podría ser cuando un usuario envía archivos almacenados en la nube a otro usuario vía correo electrónico, cuando el almacenamiento y los sistemas de correo electrónico no se relacionan más que para brindarle soporte al marco de trabajo OAuth (por ejemplo, Google Gmail y Microsoft OneDrive).
Cuando el usuario final adjunta los archivos a sus correos electrónicos y explora para seleccionar los archivos que va a adjuntar, OAuth podría utilizarse detrás de cámaras para permitir que el sistema de correo electrónico autentique y explore fácilmente en los archivos protegidos, sin requerir registrarse por segunda vez al sistema de almacenamiento de archivos. Otro ejemplo que se da en la versión OAuth 2.0 RFC, es cuando un usuario final que utiliza un servicio externo de impresión para imprimir archivos de imágenes almacenados en un servidor web no relacionado.
En todos los casos, dos o más servicios están siendo utilizados por el usuario final para una transacción, y todos los usuarios apreciarían que no se les solicite registrarse una segunda vez para lo que ellos perciben como una sola transacción. Para que OAuth funcione, el software de cliente de un usuario final (un explorador), los servicios involucrados y el proveedor de la autenticación deben darle soporte a la versión correcta de OAuth (1.0 versus 2.0).
¿Cómo funciona OAuth?
Cuando se intenta entender a OAuth, puede ser de ayuda recordar que los contextos de OAuth casi siempre implican a dos servicios o sitios web que intentan lograr algo en representación de los usuarios o su software. Los tres tienen que trabajar juntos, involucrando muchas aprobaciones para la transacción completada para conseguir autorización.
También es útil recordar que OAuth se trata de autorización en particular, y no de autenticación directamente. La autenticación es un proceso donde un usuario/sujeto está demostrando que es dueño de una identidad presentada proporcionando una contraseña u otro factor presentado o de propiedad individual. La autorización es el proceso de permitir que un sujeto acceda a recursos después de una autenticación exitosa, muchas veces en otro lugar. Muchas personas piensan que OAuth significa autenticación abierta, pero es más útil entender a OAuth pensando en esta como una AUTHorization abierta.
Un implementador temprano describe a OAuth como la llave valet de un auto, que puede usarse para permitir que el valet conduzca temporalmente el auto y lo estacione, pero esta no permite que el valet tenga un acceso completo e ilimitado al auto, como lo permite una llave regular. En cambio, el auto solo puede ser conducido unas cuantas millas, no se puede acceder a la maletera o guantera, y puede tener muchas otras limitaciones. Esencialmente, OAuth permite al usuario -a través de un proveedor de autenticación con el que previamente se han autenticado exitosamente- conceder a otra página web/servicio un token de autenticación de acceso para la autorización hacia recursos adicionales.
Asimismo, OAuth 2.0 es un marco de trabajo, no un protocolo (como la versión 1.0). Sería como si todos los fabricantes de autos se pusieran de acuerdo en cómo los valets automáticamente solicitarían, recibirían y utilizarían las llaves valet, y cuál sería en general la apariencia de esas llaves valet. Lo que hace la llave valet dependería de cada fabricante de autos. Al igual que en la vida real, a los valets y los dueños de los autos no tiene que importarles cómo funciona todo. Ellos solo quieren que todo funcione sin complicaciones cuando entregan la llave.
OAuth paso por paso
Asumamos que un usuario ya se ha registrado en una página web o servicio (OAuth solo funciona usando HTTPS). El usuario después inicia una función/transacción que necesita acceder a otro sitio web o servicio no relacionado. Sucede lo siguiente (muy simplificado):
1La primera página web que utiliza OAuth, se conecta a la segunda en representación del usuario, proporcionando la identidad verificada del usuario.
2 La segunda página web genera un token irrepetible y un secreto irrepetible para la transacción y las partes involucradas.
3 La primera página web le entrega su token y secreto al software inicial del usuario.
4 El software del cliente presenta el token y secreto de solicitud a sus proveedores de autorización (que podría ser o no ser la segunda página web).
5 Si aún no está autenticado para el proveedor de autorización, se le podría solicitar el cliente que se autentique. Después de la autenticación, al cliente se le solicita autenticarse. Después de la autenticación, al cliente se le solicita aprobar la transacción de la autorización hacia la segunda página web.
6 El usuario aprueba (o su software aprueba silenciosamente) un tipo de transacción particular en la primera página web.
7 Al usuario se le otorga un token aprobado de acceso (note que ya no se trata de un token de solicitud).
8 El usuario le entrega el token de acceso aprobado a la primera página web.
9 La primera página web le otorga el token de acceso a la segunda página web como prueba de autenticación en nombre del usuario.
10 La segunda página web le permite a la primera página web el acceso a su página en nombre del usuario.
11 El usuario ve cómo sucede una transacción completamente exitosa.
OAuth no es el primer sistema de autenticación/autorización en trabajar de esta manera en nombre del usuario final. De hecho, muchos sistemas de autenticación, en especial Kerberos, funcionan similarmente. Lo que resalta de OAuth es su habilidad de trabajar a lo largo de la web y la amplitud de su adopción. Tuvo éxito con sus niveles de adopción donde previos intentos fallaron (por varias razones).
Aunque no es tan simple como podría serlo, los codificadores de web parecen entender voluntariamente las transacciones involucradas. Hacer que una página web sea compatible con OAuth, puede realizarse en periodos que abarcan desde unas cuantas horas hasta un día (es mucho más rápido si ya la hizo anteriormente). Por un poco de esfuerzo adicional, el acceso a las páginas web autenticadas puede ser extendido a literalmente cientos de millones de usuarios adicionales. No existe la necesidad de que una página web contenga su propio sistema de autenticación con la habilidad de crecer en proporciones gigantescas. Puede encontrar un ejemplo de un paquete de transacción HTTP individual aquí.
Criticismo y soluciones de OAuth
No existen estándares universales perfectos de autenticación a nivel de toda la Internet. OAuth es particularmente criticada debido a los drásticos cambios entre la versión 1.0 y la 2.0. De muchas maneras, OAuth 2.0 es menos segura, más compleja y menos prescriptiva que la versión 1.0. Los creadores de la versión 2.0 se centraron en hacer que OAuth sea más interoperable y flexible entre sitios web y dispositivos. También introdujeron el concepto de expiración de token, que no existía en la versión 1.0. A pesar de la intención, muchos de los fundadores y seguidores originales alzaron las manos y no apoyaron a la versión 2.0.
Los cambios son tan significativos que la versión 2.0 no es compatible con la versión 1.0., e incluso las implementaciones distintas de la versión 2.0 podrían no trabajar bien una con la otra. Sin embargo, nada previene a una página web de brindarle soporte tanto a la versión 1.0 como a la 2.0., aunque los creadores de la 2.0 la introdujeron con la intención de que todas las páginas web reemplazaran por completo a la 1.0.
Una de las críticas más grandes de OAuth 2.0 es que, intencionalmente, el estándar no define o brinda soporte directamente a la codificación, firma, verificación del cliente o canal de enlace (atar una sesión o transacción en particular a un cliente y servidor en particular). En vez de eso, OAuth espera que los implementadores usen un protocolo externo de protección como Transport Layer Security (TLS), para proporcionar esas funciones.
El TLS puede brindar todas esas protecciones, pero eso depende de los implementadores, en todos los lados, para requerir que sea utilizado. Los codificadores y usuarios deberían lograr asegurar que OAuth esté operando dentro de la protección de la TLS. Los desarrolladores pueden implementar código para reforzar el uso del TLS y los usuarios deberían ser conscientes de que el TLS está siendo utilizado siempre que se les solicita ingresar credenciales de autenticación (justo como deberían hacerlo cada vez que estén ingresando credenciales).
Debido a la falta inherente de la seguridad de enlace, es posible que una página web impostora obtenga las credenciales legítimas de un usuario durante la parte del proceso donde a los usuarios se les está requiriendo autenticarse a ellos mismos para la autorización del proveedor. Por ejemplo, un usuario está usando el primer servicio y elige una función que fuerza una transacción de OAuth hacia un segundo servicio. Es posible que la primera página web finja ser la segunda, donde la autentificación del usuario está tomando lugar. La página web impostora después puede recolectar las credenciales de autentificación de los usuarios y reaccionar como si la transacción de OAuth hubiese tomado lugar de manera exitosa.
Esta no solo es una amenaza teórica. En el segundo trimestre del 2017, un millón de cuentas de Google fueron víctimas de un robo exitoso de información confidencial. Los usuarios pueden defenderse asegurándose de estar ingresando sus credenciales en el dominio de la segunda página web, y evadiendo a las páginas web que no sean transparentes. No existe un SSO perfectamente seguro y aceptado que funcione universalmente en todas las páginas web, pero con OAuth, estamos acercándonos a eso.
-Roger A. Grimes, CSO (EE.UU)
