OAuth 2.0, que significa “Open Authorization” (autorización abierta), es un estándar diseñado para permitir que un sitio web o una aplicación accedan a recursos alojados por otras aplicaciones web en nombre de un usuario. Sustituyó a OAuth 1.0 en 2012 y ahora es el estándar de facto de la industria para la autorización en línea. OAuth 2.0 proporciona acceso consentido y restringe las acciones que la aplicación del cliente puede realizar en los recursos en nombre del usuario, sin compartir nunca las credenciales del usuario.

Aunque la web es la principal plataforma para OAuth 2, la especificación también describe cómo manejar este tipo de acceso delegado a otros tipos de clientes (aplicaciones basadas en el navegador, aplicaciones web del lado del servidor, aplicaciones nativas/móviles, dispositivos conectados, etc.).

OAuth 2.0 es un protocolo de autorización y NO un protocolo de autenticación. Como tal, está diseñado principalmente como un medio para conceder acceso a un conjunto de recursos, por ejemplo, API remotas o datos de usuario.

Auth 2.0 utiliza tokens de acceso. Un Token de acceso es un dato que representa la autorización para acceder a los recursos en nombre del usuario final. OAuth 2.0 no define un formato específico para los tokens de acceso. Sin embargo, en algunos contextos, se suele utilizar el formato JSON Web Token (JWT). Esto permite a los emisores de tokens incluir datos en el propio token. Además, por razones de seguridad, los tokens de acceso pueden tener una fecha de caducidad.

La idea de los roles forma parte de la especificación central del marco de autorización OAuth2.0. Estos definen los componentes esenciales de un sistema de OAuth 2.0, y son los siguientes:

• Propietario del recurso: El usuario o sistema que posee los recursos protegidos y puede conceder acceso a ellos.

• Cliente: El cliente es el sistema que requiere acceso a los recursos protegidos. Para acceder a los recursos, el cliente debe poseer el token de acceso correspondiente.

• Servidor de autorización: Este servidor recibe las solicitudes de tokens de acceso del cliente y las emite una vez que el propietario del recurso se ha autenticado y ha dado su consentimiento. El servidor de autorización expone dos puntos de conexión: el punto de conexión de autorización, que maneja la autenticación interactiva y el consentimiento del usuario, y el punto de conexión de token, que está involucrado en una interacción de máquina a máquina.

• Servidor de recursos: Un servidor que protege los recursos del usuario y recibe las solicitudes de acceso del cliente. Acepta y valida un token de acceso del cliente y le devuelve los recursos adecuados.

Los ámbitos son un concepto importante en OAuth 2.0. Se utilizan para especificar exactamente el motivo por el que se puede conceder el acceso a los recursos. Los valores del ámbito aceptables, y los recursos a los que se refieren, dependen del servidor de recursos.

El servidor de autorización de OAuth 2 no puede devolver directamente un token de acceso después de que el propietario del recurso haya autorizado el acceso. En su lugar, y para mayor seguridad, se puede devolver un Código de Autorización, que se cambia por un token de acceso. Además, el servidor de autorización también puede emitir un Token de actualización con el token de acceso. A diferencia de los tokens de acceso, los tokens de actualización suelen tener un largo plazo de caducidad y pueden cambiarse por nuevos tokens de acceso cuando estos caducan. Dado que los tokens de actualización tienen estas propiedades, deben almacenarse de forma segura por los clientes.

En el nivel más básico, antes de poder utilizar OAuth 2.0, el cliente debe adquirir sus propias credenciales, un id de cliente y un client secret, del servidor de autorización para identificarse y autenticarse al solicitar un token de acceso.

Con OAuth 2.0, las solicitudes de acceso son iniciadas por el cliente, por ejemplo, una aplicación móvil, un sitio web, una aplicación de televisión inteligente, una aplicación de escritorio, etc. La solicitud, el intercambio y la respuesta de los tokens siguen el siguiente flujo general:

1. El cliente solicita autorización (solicitud de autorización) al servidor de autorización, proporcionando el id y el client secret como identificación; también proporciona los ámbitos y un URI de extremo (URI de redireccionamiento) al que enviar el token de acceso o el código de autorización.

2. El servidor de autorización autentica al cliente y verifica que los ámbitos solicitados están permitidos.

3. El propietario del recurso interactúa con el servidor de autorización para conceder el acceso.

4. El servidor de autorización redirige de vuelta al cliente con un código de autorización o un token de acceso, según el tipo de concesión, como se explicará en la siguiente sección. También puede devolverse un token de actualización.

5. Con el token de acceso, el cliente solicita acceso al recurso desde el servidor de recursos.

En OAuth 2.0, las concesiones son el conjunto de pasos que un cliente tiene que realizar para obtener la autorización de acceso a los recursos. El marco de autorización proporciona varios tipos de concesión para hacer frente a diferentes escenarios:

• Concesión del Código de autorización: El servidor de autorización devuelve al cliente un código de autorización de un solo uso, que se intercambia por un token de acceso. Esta es la mejor opción para las aplicaciones web tradicionales en las que el intercambio puede realizarse de forma segura en el lado del servidor. El flujo del código de autorización puede ser utilizado por aplicaciones de página única (Single Page Apps, SPA) y aplicaciones móviles/nativas. Sin embargo, en este caso, el client secret no se puede almacenar de forma segura, por lo que la autenticación durante el intercambio se limita al uso del id del cliente únicamente. Una mejor alternativa es el Código de autorización con concesión PKCE, a continuación.

• Concesión Implícita: Un flujo simplificado en el que el token de acceso se devuelve directamente al cliente. En el flujo implícito, el servidor de autorización puede devolver el token de acceso como un parámetro en el URI de devolución de llamada o como una respuesta a la publicación de un formulario. La primera opción está ahora obsoleta debido a la posible fuga de tokens.

• Concesión del código de autorización con clave de prueba para el intercambio de códigos (PKCE): Este flujo de autorización es similar a la concesión del Código de autorización, pero con pasos adicionales que lo hacen más seguro para las aplicaciones móviles/nativas y SPA.

• Tipo de concesión de credenciales del propietario del recurso: Esta concesión requiere que el cliente adquiera primero las credenciales del propietario del recurso, que se pasan al servidor de autorización. Por lo tanto, se limita a los clientes de total confianza. Tiene la ventaja de que no implica ninguna redirección al servidor de autorización, por lo que es aplicable en los casos de uso en los que una redirección es inviable.

• Tipo de concesión de credenciales de clientes: Se utiliza para aplicaciones no interactivas, por ejemplo, procesos automatizados, microservicios, etc. En este caso, la aplicación se autentica por sí misma mediante el uso de su id de cliente y su client secret.

• Flujo de autorización de dispositivos: Una concesión que permite el uso de aplicaciones en dispositivos con restricciones de entrada, como las televisiones inteligentes.

• Concesión del token de actualización: El flujo que implica el intercambio de un token de actualización por un nuevo token de acceso.

Siga leyendo en nuestra página de Introducción a IAM para explorar más temas en torno a la gestión de identidades y accesos.