OAuth 2.0

En la especificación, el RFC 6749, aparecen cuatro partes. El propietario del recurso es el usuario. El cliente es la aplicación que pide. El servidor de autorización emite tokens. El servidor de recursos los acepta. El cliente envía al usuario al servidor de autorización, el usuario consiente un alcance concreto, y el cliente recibe un token de acceso que representa ese permiso delegado y no las credenciales del usuario.

La práctica actual es el flujo de código de autorización con PKCE, definido en el RFC 7636, para todos los tipos de cliente, incluidos los confidenciales. PKCE ata el código a la instancia de cliente que inició el intercambio exigiendo una prueba de posesión al canjearlo, lo que le quita todo el valor a un código interceptado. El flujo implícito, que devolvía un token directamente a través del navegador, ya no se recomienda.

Se usa el marco como si autenticara. Una aplicación que trata la posesión de un token de acceso como prueba de la identidad del usuario está rota, porque el token dice que a una aplicación se le concedió un permiso, no que haya una persona concreta presente. La afirmación de identidad viene de OpenID Connect, en forma de un ID token que tiene una audiencia y que hay que validar como tal.

El resto de lo que encontramos es el tratamiento de las redirecciones. Una URI de redirección comparada por prefijo o por subcadena en vez de forma exacta le permite a un atacante añadir una ruta que controla y recibir el código. Un open redirect en cualquier punto de un host registrado consigue lo mismo. Los parámetros de estado que se generan y no se comprueban dejan el flujo expuesto a que lo fije un tercero. Y unos alcances pedidos con generosidad y concedidos de forma permanente hacen que una integración de poco valor acabe con acceso de lectura a un buzón por tiempo indefinido, que es una de las cosas más útiles que encontramos en un tenant.

Probamos el flujo tal y como está desplegado, no como está documentado: qué flujos sigue aceptando el servidor de autorización, si PKCE se exige o solo se admite, cómo se comparan las URI de redirección, si los tokens se validan por audiencia y emisor en el servidor de recursos, y qué les pasa a los refresh tokens cuando se revoca una sesión. El hallazgo nombra el parámetro y enseña el token que obtuvimos. La guía de mejores prácticas de seguridad vigente para el marco merece citarse en el apartado de remediación; conviene verificar la referencia actual del documento antes de que entre en un informe. Esto forma parte de cómo probamos el acceso delegado en una API.