¿Qué es el OAuth? Cómo funciona el marco de autorización abierto

0
12

Desde el comienzo de las redes distribuidas de computadoras personales, uno de los aspectos más difíciles de la seguridad informática ha sido proporcionar una experiencia de acceso sin interrupciones y de inicio de sesión único (SSO, por sus siglas en inglés) entre varias computadoras, cada una de las cuales requiere cuentas de inicio de sesión no relacionadas para acceder a sus servicios y contenido.

Aunque todavía no se ha realizado por completo en toda la Internet, ahora se puede acceder a una amplia variedad de páginas web no relacionadas usando un solo inicio de sesión físico. Puede usar su contraseña, teléfono, certificado digital, identidad biométrica, autenticación de dos factores (2FA) o autenticación (MFA) SSO de múltiples factores para iniciar sesión en un lugar. Esto hace que no tenga que ingresar otra credencial de acceso en todo el día para acceder a otras páginas más. En gran medida, tenemos que agradecerle a OAuth por eso.

Definición de OAuth
OAuth es un protocolo o marco de autorización de estándar abierto que describe cómo los servidores y servicios no relacionados pueden permitir, de forma segura, el acceso autenticado a sus activos. OAuth no necesita compartir la credencial de inicio de sesión única, relacionada e inicial. En el lenguaje de autenticación, esto se conoce como autorización delegada segura, de terceros, de agente de usuario.

Historia de OAuth
Creado, desde el principio, con un fuerte soporte por parte de Twitter, Google y otras compañías, OAuth fue lanzado como un estándar abierto en el 2010, como RFC 5849, y fue ampliamente adoptado con rapidez. Durante los siguientes dos años, se sometió a una revisión sustancial y, en el 2012, la versión 2.0 de OAuth se lanzó como RFC 6749. A pesar de que la versión 2.0 fue muy criticada por varias razones -detalladas a continuación- ganó aún más popularidad. Hoy en día, Amazon, Facebook, Instagram, LinkedIn, Microsoft, Netflix, PayPal, así como una lista de otros usuarios de Internet, lo han adoptado.

Ejemplos de OAuth
El ejemplo más simple de OAuth es cuando va a iniciar sesión en una página web, y ésta ofrece una o más oportunidades para iniciar sesión mediante el uso del inicio de sesión de otra página web/servicio. Luego, hace clic en el botón vinculado a la otra página web y la otra página web lo autentica. Luego, la página web a la que se estaba conectando originalmente lo registra por sí sola, usando el permiso obtenido de la segunda página web.

Otro ejemplo común de una situación que involucra a OAuth podría ser un usuario que envía archivos almacenados en la nube a otro usuario por correo electrónico, si es que el almacenamiento en la nube y los sistemas de correo electrónico solo están relacionados por soportar el marco de OAuth (por ejemplo, Google Gmail y Microsoft OneDrive). Cuando el usuario final adjunta los archivos a su correo electrónico y navega para seleccionar los archivos a adjuntar, OAuth podría usarse en segundo plano para permitir que el sistema de correo electrónico autentique y -sin problemas con archivos protegidos o un segundo inicio de sesión- navegue en el sistema de almacenamiento de archivos. Otro ejemplo, uno dado en el OAuth 2.0 RFC, es cuando un usuario final utiliza un servicio de impresión de terceros para imprimir archivos de imágenes almacenados en un servidor web no relacionado.

En todos los casos, el usuario final está utilizando dos o más servicios para una transacción, y cada usuario final apreciaría que no se le pida que inicie sesión por segunda vez, ya que consideran esta transacción como única. Para que OAuth funcione, el software del cliente del usuario final (un navegador, por ejemplo), los servicios involucrados y el proveedor de autenticación deben soportar la versión correcta de OAuth (1.0 versus 2.0).

OAuth explicado
Al intentar comprender OAuth, puede ser útil recordar que los contextos de OAuth casi siempre representan dos sitios o servicios no relacionados, que intentan lograr algo en nombre de los usuarios o el software de estos. Los tres tienen que trabajar juntos, involucrando múltiples aprobaciones para que la transacción completada sea autorizada.

También es útil recordar que OAuth se trata de la autorización en particular y no directamente de la autenticación. La autenticación es el proceso de un usuario/sujeto que demuestra ser propietario de una identidad presentada, al proporcionar una contraseña o algún otro factor de propiedad o presentación exclusiva. La autorización es el proceso de permitir que un sujeto acceda a los recursos después de una autenticación exitosa, a menudo en otro lugar. Mucha gente piensa que OAuth significa autenticación abierta, pero es más útil entenderlo al concebirlo como AUTHorización abierta.

Un implementador temprano describe a OAuth como algo similar a la llave valet de un automóvil, que se puede usar para permitir que un valet conduzca temporalmente y estacione un automóvil, pero no permite que el titular tenga acceso completo e ilimitado como en el caso de una llave normal. El automóvil solo se puede conducir unas pocas millas, no puede acceder a la cajuela o a la guantera cerrada, y puede tener muchas otras limitaciones. Esencialmente, a través de un proveedor de autenticación con el cual el usuario se ha autenticado previamente con éxito, OAuth le permite al usuario otorgarle a otra página web y/o servicio un token de autenticación de acceso limitado para la autorización de recursos adicionales.

Además, OAuth 2.0 es un marco, no un protocolo (como la versión 1.0). Sería como si todos los fabricantes de automóviles estuvieran de acuerdo en cómo los valets solicitarían, recibirían y usarían las llaves de valet automáticamente, y cómo se verían esas llaves de valet en general. Lo que podrían hacer las llaves de valet, en comparación con las llaves de función completa, dependería de cada fabricante de automóviles. Al igual que en la vida real, los valets y los propietarios de automóviles no necesitan preocuparse por cómo funciona todo. Solo quieren que todo funcione sin problemas cuando cedan la llave.

Cómo funciona OAuth
Supongamos que un usuario ya ha iniciado sesión en una página web o servicio (OAuth solo funciona con HTTPS). Luego, el usuario inicia una función/transacción que necesita acceder a otro sitio o servicio no relacionado. Sucede lo siguiente (muy simplificado):

  1. Utilizando OAuth, la primera página web se conecta a la segunda página web en nombre del usuario, proporcionando la identidad verificada del usuario.
  2. La segunda página web genera un token y un secreto único exclusivo de la transacción y las partes involucradas.
  3. La primera página web proporciona estetoken y secreto al software del cliente del usuario que inicia.
  4. El software del cliente presenta el token de solicitud y el secreto a su proveedor de autorización (que puede o no ser la segunda página web).
  5. Si aún no se ha autenticado con el proveedor de autorización, se le puede solicitar al cliente que se autentique. Después de la autenticación, se le pide al cliente que apruebe la transacción de autorización para la segunda página web.
  6. El usuario aprueba (o su software aprueba silenciosamente) un tipo de transacción en particular en la primera página web.
  7. El usuario recibe un tokende acceso aprobado (note que ya no es un token de solicitud).
  8. El usuario le otorga el tokende acceso aprobado a la primera página web.
  9. En nombre del usuario, la primera página web le otorga el tokende acceso a la segunda página web como prueba de autenticación.
  10. La segunda página web le permite el acceso a la primera página web en nombre del usuario.
  11. El usuario ve que se produce una transacción completada con éxito.
  12. OAuth no es el primer sistema de autenticación/autorización que funciona de esta manera en nombre del usuario final. De hecho, muchos sistemas de autenticación, especialmente Kerberos, funcionan de manera similar. Lo especial de OAuth es su capacidad para trabajar en la web y su amplia adopción. Donde fallaron intentos previos (por varias razones), OAuth tuvo éxito con las tasas de adopción.

Aunque no es tan simple como podría ser, los codificadores web parecen entender fácilmente las transacciones involucradas. Hacer que una página web sea compatible con OAuth se puede lograr en unas pocas horas hasta un día (mucho más rápido si lo ha hecho antes). A cambio de un poco de esfuerzo adicional, el acceso autenticado a la página web se puede extender a literalmente cientos de millones de usuarios adicionales. No es necesario que una página web contenga su propio sistema de autenticación con la capacidad de aumentar su escala a proporciones gigantescas. Puede encontrar un ejemplo de un paquete de transacción HTTP individual aquí.

OAuth vs. OpenID
En el mismo contexto que OAuth, existen un par de tecnologías de seguridad diferentes que podría descubrir, una de ellas es OpenID. En un nivel base, la distinción entre las dos es fácil de entender. ¿Recuerda cuando mencionamos arriba que la autenticación en OAuth significaba autorización, no autenticación? Bueno, OpenID se trata de autenticación: como lo explicó resumidamente un comentador en StackOverflow: «OpenID es para humanos que inician sesión en máquinas, OAuth es para máquinas que inician sesión en otras máquinas en representación de humanos”.

OpenID comenzó su vida el 2005 como un medio para iniciar sesión en el entonces popular sitio de blogs, LiveJournal, pero se extendió rápidamente a otros sitios. La idea, en los primeros días de la Web 2.0, era que, en lugar de tener múltiples inicios de sesión para múltiples sitios web, OpenID serviría como un inicio de sesión único, respondiendo a las identidades de los usuarios. Pero en la práctica, OpenID fue difícil de implementar por el lado del desarrollador, y nunca se volvió tan atractivo para los usuarios, especialmente porque había competencia en ese espacio. Para el 2011, OpenID se había convertido en una empresa relegada, y Wired declaró que «la razón principal por la que nadie usaba OpenID era porque Facebook Connect hacía lo mismo y lo hacía mejor. Todos sabían lo que era Facebook y era mucho más fácil entender que Facebook, en vez de algo impreciso y desconocido llamado OpenID, estaba manejando su identidad”. (Facebook Connect resultó no ser un éxito mundial tampoco, pero al menos la gente sabía lo que era Facebook).

Sin embargo, ese no es el final de la historia. En el 2014, se lanzó OpenID Connect, que reinventó OpenID como una capa de autenticación para OAuth. En este espacio, OpenID ha encontrado un nicho, y las dos tecnologías ahora se complementan entre sí en muchas implementaciones.

OAuth vs. SAML
El lenguaje de marcado de aserción de seguridad, o SAML (por sus siglas en inglés), es otra tecnología de la que escuchará hablar en el mismo aliento que OAuth. Estrictamente hablando, el nombre SAML se refiere a un lenguaje de variantes XML, pero el término también puede cubrir varios mensajes de protocolo y perfiles que forman parte del estándar SAML abierto. A diferencia de OAuth, que requiere una capa adicional como OpenID Connect para realizar la autenticación, SAML describe un marco que permite que una computadora realice autenticación y autorización en nombre de una o más computadoras. SAML, por sí solo, puede proporcionar la funcionalidad de inicio de sesión único.

SAML es más antiguo que OAuth, y de hecho uno de los factores impulsores detrás de la creación de OAuth fue que los protocolos XML, como SAML, comenzaron a pasar de moda. OAuth usa el JSON más liviano para codificar datos y, por lo tanto, tiene un mejor soporte para dispositivos móviles. En la práctica, SAML se usa con más frecuencia para aplicaciones empresariales: Salesforce, por ejemplo, lo usa para inicio de sesión único -mientras que OAuth se usa con más frecuencia en internet abierto.

OAuth2
No existen estándares perfectos de autenticación universal en Internet. OAuth está particularmente difamado debido a los cambios drásticos entre las versiones 1.0 y 2.0. En muchos sentidos, OAuth2 es menos seguro, más complejo y menos prescriptivo 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 y dispositivos. También introdujeron el concepto de vencimiento de token, que no existía en la versión 1.0. Independientemente de la intención, muchos de los fundadores y seguidores originales se exasperaron y no respaldaron 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 diferentes implementaciones de la versión 2.0 pueden no funcionar perfectamente entre sí. Sin embargo, nada impide que una página web sea compatible con 1.0 y 2.0, aunque los creadores de 2.0 lo lanzaron con la intención de que todas las páginas web reemplacen completamente la versión 1.0.

Una de las mayores críticas de OAuth 2.0 es que, intencionalmente, el estándar no define ni soporta directamente el encriptado, la firma, la verificación del cliente o el canal enlace (vincular una sesión o transacción en particular a un cliente y servidor en particular). En cambio, OAuth espera que los implementadores usen un protocolo de protección externo como Transport Layer Security (TLS), para proporcionar esas características.

¿OAuth es seguro?
TLS puede proporcionar todas esas protecciones, pero les corresponde a los implementadores, en todos los lados, exigir su uso. Los codificadores y los usuarios deben asegurarse de que OAuth se esté ejecutando dentro de la protección TLS. Los desarrolladores pueden implementar código para exigir el uso de TLS y los usuarios deben tener en cuenta que TLS se está utilizando cada vez que se les pide que ingresen credenciales de autenticación (al igual que deberían hacerlo cada vez que ingresan credenciales).

Debido a la falta de enlace de seguridad inherente, es posible que una página web informal recurra al phishing para obtener las credenciales legítimas de un usuario durante la parte del proceso en el que este debe autenticarse ante el proveedor de autorización. Por ejemplo, un usuario está utilizando el primer servicio y elige una función que fuerza una transacción de OAuth a un segundo servicio. Es posible que la primera página web falsifique la segunda página web, donde a menudo se lleva a cabo la autenticación del usuario. La página web informal puede recopilar las credenciales de autenticación del usuario y reaccionar como si la transacción de OAuth se hubiera realizado con éxito.

Esto no es solo una amenaza teórica. En el segundo trimestre del 2017, un millón de cuentas de Google fueron víctimas de phishing. La defensa es que los usuarios se aseguren de ingresar sus credenciales en el dominio de la segunda página web legítima si se les solicita credenciales, y evitar las primeras páginas web nebulosas. No existe un SSO perfectamente seguro, universalmente aceptado, que funcione en todas las páginas web, pero con OAuth, nos estamos acercando.

Roger A. Grimes, CSO