Flujos de OAuth 2.0 y tipos de tokens

OAuth 2.0 define cuatro roles. El propietario del recurso es el usuario que posee los datos (por ejemplo, sus archivos de Google Drive). El cliente es la aplicación que solicita acceso. El servidor de autorización emite tokens de acceso (por ejemplo, el servidor OAuth de Google). El servidor de recursos aloja los datos protegidos (por ejemplo, la API de Google Drive). Comprender estos roles aclara el propósito de cada flujo.

El flujo de código de autorización es el flujo adecuado para las aplicaciones web del lado del servidor. El usuario se autentica en el servidor de autorización, que redirige al cliente con un código de autorización de corta duración. El servidor del cliente intercambia este código por tokens mediante una solicitud por un canal secundario. Los tokens nunca pasan por el navegador, lo que los protege del historial del navegador y de las filtraciones a través del referente.

El flujo implícito se diseñó para aplicaciones JavaScript que se ejecutaban únicamente en el navegador y que no podían almacenar secretos del cliente de forma segura. Los tokens se devolvían directamente en el fragmento de la URL, sin pasar por el canal secundario. El flujo implícito está obsoleto en OAuth 2.1 porque PKCE (RFC 7636) permite que los clientes públicos utilicen de forma segura el flujo de código de autorización sin un secreto del cliente.

El flujo ROPC permite que los clientes recopilen directamente el nombre de usuario y la contraseña del usuario y los intercambien por tokens. Estaba pensado para clientes propios altamente confiables, pero contradice fundamentalmente el propósito de OAuth, que es impedir que las aplicaciones vean las credenciales de los usuarios. Está obsoleto en OAuth 2.1 y no debería utilizarse en ninguna aplicación nueva.

El flujo de credenciales del cliente está destinado a la autenticación entre máquinas (M2M), cuando no interviene ningún usuario. El cliente se autentica directamente en el servidor de autorización mediante su ID de cliente y su secreto, y recibe un token de acceso para uso propio. Casos de uso habituales: trabajos en segundo plano, comunicación entre microservicios y gateways de API que acceden a servicios backend.

El flujo de autorización de dispositivos (RFC 8628) permite utilizar OAuth en dispositivos con capacidades de entrada limitadas: televisores inteligentes, consolas de videojuegos, impresoras y dispositivos IoT. El dispositivo muestra un código corto y una URL. El usuario visita la URL desde un teléfono o un ordenador para autorizar el acceso. El dispositivo consulta periódicamente el servidor de autorización hasta que el usuario completa la autorización.

OAuth 2.0 define dos tipos de tokens de acceso. Los tokens opacos son cadenas aleatorias que el servidor de recursos valida llamando al endpoint de introspección del servidor de autorización. Los tokens de acceso JWT son autónomos: el servidor de recursos puede validarlos localmente verificando la firma, lo que reduce las llamadas a la API de introspección, pero requiere gestionar las claves.

Los tokens de actualización son credenciales de larga duración que se utilizan para obtener nuevos tokens de acceso cuando caduca el token de acceso. La rotación de tokens de actualización (obligatoria en OAuth 2.1 para clientes públicos) emite un nuevo token de actualización con cada uso e invalida el anterior. Si se utiliza un token de actualización robado, el cliente legítimo detecta la invalidación, lo que permite detectar el robo del token.

RFC 7662 define el endpoint de introspección de tokens, que permite a los servidores de recursos consultar al servidor de autorización el estado actual (active/inactive), el alcance, el sujeto y la caducidad de un token de acceso opaco. La introspección permite revocar tokens en tiempo real: una vez revocado un token en el servidor de autorización, las llamadas de introspección devuelven inmediatamente active: false.

RFC 7009 define el endpoint de revocación de tokens, que permite a los clientes notificar al servidor de autorización que un token (de acceso o de actualización) debe invalidarse. Se utiliza durante el cierre de sesión o cuando un cliente detecta actividad sospechosa. Los tokens de acceso JWT no se pueden revocar por completo sin una lista de revocación, porque los servidores de recursos los validan localmente sin ponerse en contacto con el servidor de autorización.

Los alcances de OAuth 2.0 definen los permisos específicos que solicita el cliente. El servidor de autorización presenta los alcances solicitados al usuario para que los apruebe. Los servidores de recursos aplican los requisitos de alcance en cada endpoint. Se aplica el principio de mínimo privilegio: los clientes solo deberían solicitar los alcances mínimos necesarios y los servidores de recursos deberían rechazar las solicitudes con un alcance insuficiente.

¿Qué flujo de OAuth 2.0 es adecuado para una herramienta CLI o un dispositivo IoT que necesita autenticar a un usuario, pero no dispone de navegador ni teclado?

El flujo de código de autorización es adecuado para las aplicaciones del lado del servidor. El flujo implícito está obsoleto (utilice PKCE en su lugar). El flujo ROPC está obsoleto (elimina el propósito de OAuth). Las credenciales del cliente se utilizan para M2M. La autorización de dispositivos permite gestionar dispositivos con entrada limitada. Los tokens de acceso pueden ser opacos o JWT. Los tokens de actualización deberían rotarse. La introspección (RFC 7662) y la revocación (RFC 7009) completan la gestión de tokens.