¿Qué es OAuth (autorización abierta)?

Los sitios web y las aplicaciones de terceros que preguntan a los usuarios "¿Iniciar sesión con Google?" o "¿Permitir el acceso a la información de su cuenta?" son casos de uso comunes de OAuth. El protocolo OAuth permite a los usuarios conceder a estas aplicaciones acceso a los datos de su cuenta fácilmente sin compartir sus credenciales de usuario.

Además de las aplicaciones web, OAuth también puede otorgar acceso a recursos a API, aplicaciones del lado del servidor, aplicaciones nativas del sistema operativo, aplicaciones móviles y dispositivos como smart TV y electrodomésticos. En algunos casos, no hay ningún usuario humano involucrado, ya que OAuth puede autorizar el acceso a la aplicación en nombre de una organización o cuenta comercial.

OAuth ofrece importantes beneficios de gestión de acceso a usuarios, desarrolladores y empresas al mantener inaccesibles los datos de inicio de sesión y limitar el acceso a otra información confidencial. También facilita que las aplicaciones accedan a la información necesaria de la cuenta sin las vulnerabilidades de seguridad de compartir credenciales de usuario.

Al simplificar el acceso seguro, OAuth puede ayudar a las organizaciones a abordar algunos de sus mayores desafíos de seguridad. Por ejemplo, un estudio del IBM Institute for Business Value reveló que 52 % de los ejecutivos afirman que la complejidad es el mayor impedimento para sus operaciones de ciberseguridad.

Un pequeño equipo de desarrolladores de software lanzó OAuth 1.0 en 2007. Esta primera versión del protocolo fue diseñada como una alternativa a la autenticación basada en la web, que exigía a los usuarios compartir sus nombres de usuario y contraseñas con servicios de terceros. Sin embargo, OAuth 1.0 proporcionaba flujos de autorización solo para sitios web.

En 2012, el Grupo de Trabajo de Ingeniería de Internet (IETF, por sus siglas en inglés) publicó OAuth 2.0 como RFC 6749 y RFC 6750. Una RFC (solicitud de comentarios) es un documento IETF que describe los protocolos de comunicación de Internet. RFC 6749 es la infraestructura principal para OAuth 2.0, y RFC 6750 define cómo la infraestructura usa tokens de acceso.

Esta versión actualizada de OAuth amplió el protocolo para abarcar no solo a los navegadores sitio web e incluir capacidades de autorización para aplicaciones, API y dispositivos. OAuth 2.0 reemplazó a OAuth 1.0 y ahora es el estándar de la industria.

A diferencia de otros marcos que dependen de nombres de usuario y contraseñas, OAuth es un protocolo de autorización que se basa en tokens de acceso. Los tokens de acceso son piezas de información que determinan los recursos específicos a los que una aplicación puede acceder. El protocolo OAuth define cómo cada componente en un proceso de solicitud de autorización aprueba, define y gestiona los tokens de acceso.

Los tokens OAuth comúnmente usan el estándar JSON Web Token (JWT) debido a su capacidad para transmitir datos de manera segura.

Los componentes principales de la infraestructura de OAuth son:

• Propietario del recurso
• Servidor del recurso
• Cliente
• Servidor de la autorización
• Determinar

A continuación se muestra una descripción general básica de cómo podría funcionar un flujo de OAuth:

1. Jim (el propietario del recurso) quiere permitir que un sitio de redes sociales (el cliente) acceda a sus contactos de correo electrónico (el recurso).
   
   
2. El servidor de autorización de correo electrónico solicita a Jim que dé su consentimiento para este acceso.
   
   
3. Tras recibir el consentimiento de Jim, el servidor de autorización proporciona al sitio de redes sociales un token de acceso.
   
   
4. El sitio de redes sociales presenta el token de acceso al servidor de recursos que almacena la información de la cuenta de correo electrónico de Jim.
   
   
5. El servidor de recursos reconoce el token de acceso y otorga al sitio de redes sociales acceso a los contactos de correo electrónico de Jim. Debido a que el token de acceso incluye el alcance del consentimiento de Jim, el sitio de redes sociales no puede acceder a ningún otro dato de la cuenta de Jim.

El procedimiento para proporcionar un token de acceso a una aplicación se denomina concesión de autorización o flujo de autorización. Existen diferentes tipos de concesiones y flujos de OAuth que se pueden usar para diferentes tipos de aplicaciones, dispositivos o API, como:

• Código de autorización
• Clave de prueba para el intercambio de códigos (PKCE)
• Credenciales del cliente
• Concesión implícita
• Actualizar token

Este tipo de concesión se utiliza normalmente para aplicaciones web y aplicaciones móviles. En un flujo de código de autorización, el servidor de autorización proporciona un código de autorización de un solo uso al cliente. A continuación, el cliente puede intercambiar ese código de autorización por un token de acceso desde el endpoint del token del servidor de autorización.

Este flujo añade seguridad adicional a la concesión de código de autorización para proteger las aplicaciones de los ataques de inyección de código. Este tipo de ataques pueden engañar a las aplicaciones para que ejecuten código malicioso que cambia la forma en que operan.

PKCE agrega un "secreto de cliente" que autentica al cliente con el servidor de autorización antes de que se emita un token de acceso. Debido a que solo el cliente legítimo tiene el secreto, los actores maliciosos no pueden fingir ser el cliente e introducir código malicioso.

Este tipo de concesión está diseñado para situaciones en las que no participa ningún usuario humano, como procesos automatizados, interacciones máquina a máquina y microservicios.

Las aplicaciones tienen acceso a los recursos del sistema que necesitan para ejecutar funciones, pero no a los recursos de los usuarios finales. Por ejemplo, la concesión de credenciales de cliente podría permitir que una aplicación meteorológica acceda a una API para recuperar datos sobre el pronóstico más reciente.

Este tipo de concesión proporciona un flujo más simple para las aplicaciones sitio web de JavaScript. A diferencia de la concesión del código de autorización, el flujo implícito no requiere un código de autorización antes de emitir un token de acceso.

En cambio, después de que el usuario da su consentimiento, el token de acceso se incluye en el identificador uniforme de recursos (URI, por sus siglas en inglés) de redireccionamiento que devuelve al usuario a la aplicación que aplicar el acceso. La aplicación obtiene el token de acceso del URI.

Si un token de acceso ha vencido, este tipo de concesión proporciona a la aplicación un token de actualización que puede cambiarse por un nuevo token de acceso. Si el usuario final no tiene un token de actualización, tendría que volver a dar su consentimiento para que la aplicación reciba un nuevo token de acceso.

La diferencia fundamental es que el inicio de sesión único (SSO) es un protocolo de autenticación de usuarios y OAuth es un protocolo de autorización.

El SSO suele utilizar un proveedor de identidad (IdP) y el lenguaje de marcado de aserción de seguridad (SAML), basado en el lenguaje de marcado extensible (XML), para autenticar las identidades digitales de los usuarios por medio de nombres de usuario y contraseñas.

OAuth no autentica a los usuarios, sino que los autoriza a acceder a los recursos del sistema. Las soluciones de SSO a veces usan OAuth para proporcionar a los usuarios autenticados un acceso fácil a las aplicaciones y servicios en toda la empresa.

OpenID Connect (OIDC) es un protocolo de autenticación que se basa en OAuth 2.0. Si se combinan los dos, OpenID Connect puede verificar la identidad de un usuario y luego OAuth puede autorizar a ese usuario a acceder a recursos y servicios.