¿Qué es OAuth? {Definición, terminología y prácticas}

13 de Octubre de 2022

Introducción

La aparición y popularización de API permitió el intercambio masivo de datos. Sin embargo, un gran porcentaje de los datos compartidos no es de uso público. Como resultado, los desarrolladores de API comenzaron a buscar formas de evitar que personas no autorizadas accedieran a recursos valiosos. Aquí es donde inteligencia de identidad y acceso juega un papel crucial.

Los desarrollos en el campo de la identidad y la inteligencia de acceso dieron como resultado numerosas herramientas de protección de datos que los propietarios de API utilizan a diario. Una de esas herramientas es el protocolo de autorización abierta u OAuth.

Siga leyendo para descubrir qué es OAuth, cómo funciona y cómo implementarlo siguiendo las mejores prácticas de seguridad.  

¿Qué es OAuth y cómo funciona?

Definición de OAuth

OAuth es un protocolo de autorización diseñado para otorgar acceso a una aplicación a los recursos alojados por otras aplicaciones web en nombre de un usuario. Se considera el estándar de la industria para la autorización en línea y un componente esencial de los sistemas de seguridad API. 

OAuth 1.0 frente a OAuth 2.0 

La primera versión de OAuth debutó en 2007, pero fue reemplazada por OAuth 2.0 en 2012 debido a problemas de implementación. Desde entonces, OAuth 1.0 se ha considerado obsoleto y los proveedores de API ya no usan esta versión del protocolo. 

Aquí hay un resumen de las diferencias entre las dos versiones.

  •  OAuth 1.0 es independiente del transporte, lo que significa que el protocolo no delega la seguridad a otros protocolos de seguridad, como HTTPS y TLS. OAuth 2.0 delega la mayoría de las tareas de seguridad a HTTPS y TLS, haciendo que las conexiones sean más vulnerables a ataques de hombre en el medio
  • OAuth 1.0 se basa en la criptografía, lo que significa que utiliza firmas digitales como herramienta de autorización. OAuth 2.0 utiliza tokens de portador, que son más fáciles de implementar, pero no cuentan con mecanismos de seguridad internos. 
  • OAuth 2.0 es más fácil de usar, pero también presenta más desafíos de seguridad. 

OAuth frente a SAML

OAuth y Lenguaje de marcado de aserción de seguridad (SAML) son similares en que son protocolos web que otorgan acceso a aplicaciones web. Sin embargo, difieren en varios aspectos. 

La principal diferencia entre los dos es que OAuth es un autorización mientras que SAML es un protocolo autenticación protocolo.  

Con autenticación, el usuario final debe declarar su identidad ingresando sus credenciales cada vez que desee acceder a ciertos recursos. Con autorización, el servidor reconoce al usuario como alguien a quien ya se le ha otorgado acceso y le pide autorización al servidor, no el usuario, para un token de confirmación. 

La ventaja de OAuth sobre SAML es que un usuario puede cambiar sin problemas entre aplicaciones integradas sin tener que iniciar sesión en cada una de ellas individualmente. 

Veamos un entorno de trabajo como ejemplo. Normalmente, las empresas utilizan decenas de aplicaciones web para sus procesos. Con OAuth, un empleado puede iniciar sesión en un entorno de trabajo una vez y usar todas las aplicaciones integradas sin tener que ingresar sus credenciales en cada una por separado. 

Una breve historia de OAuth

  • Noviembre 2006 – Los desarrolladores de aplicaciones web se dan cuenta de que no existen estándares abiertos para la delegación de acceso a API, lo que crea la idea de OAuth. 
  • Abril de 2007 – Formación del grupo de discusión de OAuth. 
  • Julio 2007 – Redacción del pliego de condiciones inicial. 
  • Diciembre 2007 – Lanzamiento del borrador final bajo el nombre OAuth Core 1.0. 
  • Agosto 2010 – Publicación del marco OAuth 1.0 en RFC (Solicitud de comentarios), una base de conocimiento para Internet y sistemas conectados a Internet, con el número 5849. Todas las aplicaciones de Twitter de terceros deben usar OAuth. 
  • Octubre 2012 – Publicación del framework OAuth 2.0 y la guía de Uso del Token Portador en la Solicitud de Comentarios bajo los números 6749 y 6750, respectivamente. 
  • PresenteOAuth 2.1 se encuentra en etapa de borrador. 

Nota: La información proporcionada se basa en los datos disponibles al momento de escribir este artículo (septiembre de 2022) y está sujeta a cambios. 


Terminología importante de OAuth 2.0 

Las siguientes son definiciones de terminología asociada con el marco OAuth 2.0. 

Funciones de OAuth 2.0 

Los roles que participan en el proceso de autorización de OAuth 2.0 se describen a continuación. 

  • Propietario del recurso – El usuario o sistema que posee los recursos API protegidos y puede otorgarles acceso. 
  • Cliente – El sistema que solicita acceso a los recursos protegidos mediante el token de acceso adecuado. 
  • servidor de autorización – El servidor que recibe las solicitudes de los clientes de tokens de acceso y las emite con la autenticación y el consentimiento otorgados por el propietario del recurso. 
  • servidor de recursos – El servidor que contiene recursos protegidos y los emite al recibir una solicitud válida que contiene un token de acceso válido. 

Ámbitos de OAuth 2.0

Los ámbitos de OAuth son los motivos por los que se puede conceder acceso a los clientes a los recursos protegidos. El propietario del recurso determina qué valores de ámbito son aceptables y con qué recursos se relacionan los ámbitos. 

Fichas de OAuth 2.0 

Los tokens de OAuth son cadenas de datos que contienen las credenciales de seguridad necesarias para acceder a los recursos protegidos.  

Los tokens permiten a los servidores de recursos identificar al propietario del token, los grupos a los que pertenece el propietario y el nivel de acceso que tiene el usuario. Sin embargo, ninguna de esta información se divulga al servidor de autorización, ya que el marco de OAuth está diseñado para no exponer las credenciales del cliente. 

Los dos tipos de tokens de OAuth son: 

  • Actualizar tokens – Un token de actualización permite que un cliente genere, actualice y revoque un token de acceso a corto plazo. Los tokens de actualización se envían al servidor de autorización. Su uso no es obligatorio pero se recomienda como buena práctica de seguridad. 
  • fichas de acceso – Se envía un token de acceso al servidor de recursos, que luego otorga acceso a los recursos protegidos. Su corto tiempo de caducidad evita fugas de tokens y violaciones de seguridad. 

Hay dos tipos de tokens de acceso: 

  • fichas de portador – Estos tokens se basan en la seguridad HTTPS. Las solicitudes realizadas con estos tokens no están firmadas ni encriptadas. Los tokens de portador pueden no estar estructurados (una cadena corta de caracteres hexadecimales) o estructurados (p. ej., tokens web JSON). 
  • Tokens de código de autenticación de mensajes (MAC) – Estos tokens permiten que las solicitudes se verifiquen parcialmente criptográficamente. 

Código de autorización de OAuth 2.0 

Los servidores de autorización se pueden configurar para devolver un código de autorización en lugar de un token de acceso.  

Los códigos de autorización se utilizan para obtener tokens de acceso y funcionan de manera muy similar a los tokens de actualización. Un código de autorización y un token de actualización se diferencian en que el primero es para un solo uso y tiene un tiempo de vencimiento, mientras que el segundo se puede usar un número indefinido de veces. 

Subvenciones de OAuth 2.0 

Las concesiones representan conjuntos de pasos que un cliente debe completar antes de obtener acceso a los recursos solicitados. Diferentes flujos requieren diferentes tipos de concesión, y el marco OAuth permite lo siguiente:  

  • Subvención implícita – Es un flujo en el que el servidor de autorización devuelve el token de acceso directamente al cliente a través del navegador. Enlance. Tras una solicitud, se redirige al usuario a una página de OAuth y se le pide que autorice los permisos. Cuando el usuario lo hace, se le redirige a la aplicación con un token de acceso. Esta concesión rara vez se usa porque los tokens de acceso expuestos representan una amenaza para la seguridad, pero cuando se usa, es para aplicaciones de JavaScript de una sola página. La simplicidad de este flujo se ve eclipsada por el esfuerzo que se necesita para asegurarlo. 
  • Subvención de token de actualización: Lo utilizan los clientes para intercambiar un token de actualización por un token de acceso sin necesidad de volver a autenticarse. Este flujo es uno de los más utilizados porque la participación de dos tokens proporciona el equilibrio adecuado entre seguridad y usabilidad. Los tokens de actualización funcionan con aplicaciones web, nativas y de una sola página. 
  • Concesión de código de autorización - Funciona mejor para aplicaciones web tradicionales porque el intercambio secreto ocurre en el lado del servidor. Al recibir la solicitud de un cliente, el servidor de autorización devuelve un código de autorización de un solo uso que el cliente intercambia por un token de acceso. Las aplicaciones móviles, nativas y de una sola página requieren medidas de seguridad adicionales porque los secretos de los clientes no se pueden almacenar de forma segura en dichas arquitecturas. 
  • Concesión de código de autorización con clave de prueba para intercambio de código (PKCE) - Implica el uso de un código de autorización de un solo uso. Este flujo cumple con las necesidades de seguridad requeridas para aplicaciones móviles, nativas y de una sola página. 
  • Concesión de credenciales de propietario de recursos - Reservado para clientes de confianza (es decir, un sistema operativo o una aplicación con muchos privilegios). El cliente debe adquirir las credenciales del propietario del recurso y enviarlas al servidor de autorización. Los servidores de autorización deben habilitar este tipo de concesión solo en los casos en que otros flujos no sean viables. 
  • Concesión de credenciales de cliente - Diseñado para aplicaciones no interactivas (aplicaciones sin intervención del usuario) como microservicios y procesos automatizados. El servidor de autorizaciones autentica la aplicación cliente utilizando su ID y secreto de cliente. 
  • Flujo de autorización de dispositivos - Un tipo de concesión que permite el acceso a aplicaciones en dispositivos con restricciones de entrada, como televisores inteligentes, relojes inteligentes, dispositivos domésticos inteligentes, etc. 

¿Cómo funciona OAuth?

Un proceso de autorización mediante OAuth 2.0 consta de los siguientes pasos: 

  1. Una aplicación cliente envía una solicitud de autorización al servidor de autorización que contiene una identificación de cliente, un secreto de cliente, ámbitos requeridos y un URI de punto final. 
  2. El servidor de autorización autentica al cliente utilizando la identificación del cliente y verifica si los ámbitos solicitados están permitidos. 
  3. Si la solicitud es válida, el cliente autenticado y los ámbitos permitidos, el servidor de autorización solicita una credencial de autorización (token de acceso o código de autorización) del servidor de recursos. 
  4. El servidor de recursos proporciona la credencial de autorización. 
  5. El servidor de autorización pasa la credencial al cliente. 
  6. El cliente ahora solicita acceso al servidor de recursos utilizando la credencial que recibió. 
Representación visual del flujo de trabajo de OAuth 2.0.

Ejemplo de OAuth

La API de transacción RESTful de CCBill utiliza tokens de portador para la autorización.  

Antes de que los comerciantes puedan usar la API para administrar sus transacciones, deben registrar su aplicación, después de lo cual CCBill les proporciona una identificación de aplicación comercial y una clave secreta. Estas credenciales luego se utilizan para generar un token de acceso. 

El URI del servidor de autorización de CCBill es https://api.ccbill.com/ccbill-auth/oauth/token

Solicitud de token de acceso – rizo ejemplo: 

curl -X POST  
\ 
'https://api.ccbill.com/ccbill-auth/oauth/token'  
\ 
    -i -u 'MERCHANT_APPLICATION_ID:APPLICATION_SECRET'  
\ 
    -H 'Content-Type: application/x-www-form-urlencoded'  
\ 
    -d 'grant_type=client_credentials' 

Una vez que reciben un token de acceso, los comerciantes deben proporcionarlo en el encabezado de Autorización de cada solicitud de API que realicen. 

Implementación de OAuth 2.0: mejores prácticas 

Debido a que OAuth 2.0 delega la seguridad en los protocolos de seguridad, los propietarios de API que usan OAuth 2.0 deben asegurarse de que la implementación de sus medidas de seguridad sea infalible. Las mejores prácticas asociadas con la implementación segura de OAuth 2.0 son las siguientes: 

Use SSL

Para establecer conexiones OAuth 2.0, los servidores de autorización deben obtener una SSL or TLS certificado. Este es un requisito previo obligatorio dentro de la Marco OAuth 2.0 y tiene como objetivo prevenir ataques de hombre en el medio

Configurar comprobaciones de certificados SSL (para aplicaciones móviles) 

navegadores web realizar comprobaciones en las aplicaciones web de forma predeterminada y advertir a los usuarios si el certificado no es fiable. 

No almacene los secretos de los clientes en texto sin formato  

Los propietarios de API que deseen conservar los secretos de los clientes deben almacenarlos en sus valores hash. Almacenar los secretos de los clientes en texto sin formato compromete seriamente la seguridad porque, en caso de una violación, los secretos son fácilmente accesibles. 

Usar fichas de actualización 

Los tokens de actualización son credenciales que se utilizan para obtener tokens de acceso de corta duración. Usar tokens de actualización en lugar de confiar solo en tokens de acceso es más seguro por las siguientes razones: 

  • Un token de acceso se intercambia directamente con el servidor de recursos, mientras que un token de actualización se intercambia con un servidor de autorización. Por lo tanto, se minimizan las posibilidades de que se filtre un token de acceso. 
  • Los tokens de actualización permiten a los propietarios de aplicaciones cliente revocar un token de acceso de corta duración, en caso de que surja la necesidad. 
  • Un token de actualización viaja más rápido que un token de acceso, lo que les da a los piratas informáticos menos tiempo para realizar ataques de intermediarios. 
  • La actividad maliciosa es más fácil de detectar porque los tokens de acceso caducados solo se pueden reemplazar enviando una solicitud con el token de actualización al que está vinculado. Imaginemos que un pirata informático obtiene un token de acceso y el token de actualización asociado con él. Cuando el token de acceso expire, deberán enviar una solicitud de actualización con el token de actualización. Los operadores de servidores podrían detectar actividades sospechosas debido a cambios en el comportamiento del usuario (por ejemplo, una dirección IP diferente desde la que se envía la solicitud). 

Conclusión

Comprende qué es OAuth y cómo se utiliza para proteger los procedimientos de autorización, las transferencias de credenciales y las transferencias de recursos entre aplicaciones web. 

Acerca del autor.
Mirjana Fodora
Mirjana Fodora es escritora técnica con experiencia en diseño y desarrollo web. A pesar de ser uno de los miembros más jóvenes de CCBill, sus habilidades de escritura y aptitud técnica la ayudan a producir contenido fáctico, informativo y fácil de usar. Si no está escribiendo o aprendiendo una nueva habilidad, la encontrará atracándose de fintech y videos de marketing o juegos.
Hable con un especialista en asistencia comercial