Publicado: 29 de julio de 2024
Colaboradores: Gregg Lindemulder y Matt Kosinski
La autorización abierta (OAuth) es una infraestructura de autorización de estándar abierto que otorga a las aplicaciones acceso 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.
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.
Descubra por qué KuppingerCole afirma que IBM es líder en el suministro de soluciones de autenticación empresarial maduras, escalables y seguras.
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.
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 web, en la que los usuarios deben 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, 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
Este es el usuario final que es el propietario de 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 ciertos recursos protegidos en esa cuenta, como fotos o datos personales. En algunos casos, el propietario del recurso puede ser una empresa o cuenta empresarial.
Este es el servidor que almacena los recursos protegidos en nombre del usuario. El servidor del recursos acepta y valida los tokens de OAuth que recibe del cliente y, a continuación, proporciona al usuario los datos que el propietario del recurso dio su consentimiento para divulgar.
El cliente es la aplicación, sitio web, API o dispositivo que solicita acceso. Solicita autorización del servidor de autorización presentando un ID de cliente. Luego, después de que el propietario del recurso dé su consentimiento, el cliente recibe un token de acceso que puede usar para acceder a los recursos protegidos en el servidor de recursos.
Este es el servidor principal que impulsa el protocolo OAuth. Opera dos endpoints para otorgar acceso al servidor de recursos.
El endpoint de autorización solicita al propietario del recurso que proporcione su consentimiento para recursos protegidos específicos. Luego, el endpoint del token recibe la solicitud del token del cliente de OAuth y genera nuevos tokens de acceso que otorgan acceso a los recursos.
Los alcances son los parámetros de acceso a 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 alcance restringe el acceso del cliente solo a esos elementos.
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 solicita a Jim que dé su consentimiento para este acceso.
- Tras 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 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 llevar a cabo funciones, pero no tienen acceso a los recursos del usuario final. Por ejemplo, la concesión de credenciales de un 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 usar 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 a través 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 funcionan en conjunto, OpenID Connect puede verificar la identidad de un usuario, luego OAuth puede autorizar a ese usuario a acceder a recursos y servicios.
Proteja y gestione las identidades de clientes, fuerza laboral y privilegiadas en toda la nube híbrida, infundidas con IA.
Agregue contexto profundo, inteligencia y seguridad al acceso de los usuarios de sus datos y aplicaciones.
Proteja, controle y medie el acceso a sus API para protegerlas de amenazas cada vez más graves.
Obtenga insights esenciales para ayudar a sus equipos de seguridad y TI a gestionar mejor el riesgo y las pérdidas potenciales.
Conozca las últimas tácticas de ciberataques para proteger mejor a su personal, datos e infraestructura.
En un sistema informático, la autenticación (“auth” para abreviar) es el proceso que verifica que un usuario sea quien dice ser.