29 de julio de 2024
Open Authorization (OAuth)es un marco de autorización estándar abierto que permite a las aplicaciones acceder a los recursos protegidos de un usuario final, como sus fotos, calendarios o publicaciones en redes sociales, sin requerir el inicio de sesión o la contraseña de la cuenta del usuario.
Sitios web y aplicaciones de terceros que solicitan a los usuarios "¿Acceder con Google?" o "¿Permitir el acceso a la información de tu cuenta?" son casos de uso comunes para OAuth. El protocolo OAuth permite a los usuarios conceder fácilmente a estas aplicaciones acceso a los datos de su cuenta 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 televisores inteligentes 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.
Refuerce su inteligencia de seguridad
Manténgase a la vanguardia de las amenazas con noticias e información sobre seguridad, IA y mucho más, semanalmente en el boletín Think.
OAuth ofrece importantes beneficios de administración de acceso a usuarios, desarrolladores y empresas al mantener los datos de inicio de sesión inaccesibles y limitar el acceso a otra información confidencial. También facilita a las aplicaciones el acceso a la información necesaria de la cuenta sin las vulnerabilidades de seguridad que supone compartir las 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 descubrió que el 52 % de los ejecutivos dicen 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 se diseñó como una alternativa a la autenticación basada en la web, que requería a los usuarios compartir sus nombres de usuario y contraseñas con servicios de terceros. Sin embargo, OAuth 1.0 proporcionó flujos de autorización solo para sitios web.
En 2012, el Grupo de Trabajo de Ingeniería de Internet (IETF) publicó OAuth 2.0 como RFC 6749 y RFC 6750. Un RFC (Request for Comments) es un documento del IETF que describe protocolos de comunicación de Internet. El RFC 6749 es el marco central de OAuth 2.0, y el RFC 6750 define cómo utiliza el marco los tokens de acceso.
Esta versión actualizada de OAuth amplió el protocolo más allá de los navegadores web para 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 se basan en 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 elementos de información que determinan los recursos específicos a los que puede acceder una aplicación. El protocolo OAuth define cómo cada componente de un proceso de solicitud de autorización aprueba, define y gestiona los tokens de acceso.
Los tokens OAuth comúnmente utilizan el estándar JSON Web Token (JWT) debido a su capacidad para transmitir datos de forma segura.
Los componentes principales del marco OAuth son:
- Propietario del recurso
- Servidor de recursos
- Cliente
- Servidor de autorización
- Ámbito
Este es el usuario final que posee la cuenta a la que la aplicación busca acceder, como una cuenta de Facebook o Google. El propietario del recurso da su consentimiento para que la aplicación acceda a determinados recursos protegidos de esa cuenta, como fotos o datos personales. En algunos casos, el propietario del recurso puede ser una cuenta de empresa o negocio.
Este es el servidor que almacena los recursos protegidos en nombre del usuario. El servidor de recursos acepta y valida los tokens OAuth que recibe del cliente y, a continuación, proporciona los datos del usuario que el propietario del recurso ha consentido liberar.
El cliente es la aplicación, el sitio web, la API o el dispositivo que solicita el acceso. Solicita autorización al servidor de autorización presentando un ID de cliente. Entonces, después de que el propietario del recurso dé su consentimiento, el cliente recibe un token de acceso que puede utilizar para acceder a los recursos protegidos en el servidor de recursos.
Este es el servidor principal que impulsa el protocolo OAuth. Opera dos puntos de conexión para conceder acceso al servidor de recursos.
El endpoint de autorización solicita al propietario del recurso que dé su consentimiento para determinados recursos protegidos. A continuación, el endpoint de tokens recibe la solicitud de tokens del cliente OAuth y genera nuevos tokens de acceso que conceden acceso a los recursos.
Los ámbitos son los parámetros de acceso para los recursos protegidos en el servidor de recursos.
Por ejemplo, se puede pedir al propietario del recurso que dé su consentimiento para acceder a datos como correos electrónicos, archivos o fotos. El ámbito restringe el acceso del cliente solo a esos elementos.
Ejemplo de flujo de OAuth
A continuación, se muestra una descripción general básica de cómo podría funcionar un flujo de OAuth:
- 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).
- El servidor de autorización de correo electrónico le pide a Jim que dé su consentimiento para este acceso.
- Después de recibir el consentimiento de Jim, el servidor de autorización proporciona al sitio de redes sociales un token de acceso.
- 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.
- El servidor de recursos reconoce el token de acceso y concede al sitio de redes sociales acceso a los contactos de correo electrónico de Jim. Dado que el token de acceso incluye el alcance del consentimiento de Jim's, 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 utilizar 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 de cliente
- Concesión implícita
- Actualizar ficha
Código de autorización
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 punto de conexión del token del servidor de autorización.
Clave de prueba para el intercambio de códigos (PKCE)
Este flujo agrega seguridad adicional a la concesión del código de autorización para proteger las aplicaciones de ataques de inyección de código. Este tipo de ataques pueden engañar a las aplicaciones para que ejecuten códigos malintencionados que cambien su funcionamiento.
PKCE añade 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 malintencionados no pueden hacerse pasar por el cliente e introducir código malicioso.
Credenciales de cliente
Este tipo de subvención está diseñado para situaciones en las que no hay ningún usuario humano involucrado, como procesos automatizados, interacciones de máquina a máquina y microservicios.
A las aplicaciones se les concede acceso a los recursos del sistema que necesitan para llevar a cabo funciones, pero no se les concede acceso a los recursos del usuario final. Por ejemplo, una concesión de credenciales de cliente podría permitir que una aplicación meteorológica acceda a una API para recuperar datos sobre la previsión más reciente.
Concesión implícita
Este tipo de concesión proporciona un flujo más sencillo para las aplicaciones web de JavaScript. A diferencia de la concesión de código de autorización, el flujo implícito no requiere un código de autorización antes de que se emita un token de acceso.
En su lugar, una vez que el usuario da su consentimiento, el token de acceso se incluye en el identificador uniforme de recursos (URI)de redireccionamientoque devuelve al usuario a la aplicación que solicita acceso. La aplicación obtiene el token de acceso del URI.
Actualizar ficha
Si un token de acceso ha caducado, este tipo de concesión proporciona a la aplicación un token de actualización que puede intercambiarse por un nuevo token de acceso. Sin un token de actualización, el usuario final tendría que volver a dar su consentimiento para que la aplicación recibiera 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), que se basa en el Lenguaje de Marcado Extensible (XML), para autenticar las identidades digitales de los usuarios mediante nombres de usuario y contraseñas.
OAuth no autentica a los usuarios, pero los autoriza a acceder a los recursos del sistema. Las soluciones de SSO a veces usan OAuth para proporcionar a los usuarios autenticados un fácil acceso a las aplicaciones y servicios de una empresa.
OpenID Connect (OIDC) es un protocolo de autenticación que se basa en OAuth 2.0. Al trabajar juntos, OpenID Connect puede verificar la identidad de un usuario y, a continuación, OAuth puede autorizar a ese usuario a acceder a los recursos y servicios.