Claves de API u OAuth para integraciones de terceros

Qué es

Una clave de API es un secreto estático que se emite a una aplicación y se envía en cada solicitud. La OWASP REST Security Cheat Sheet (citada) presenta las claves como un control contra el abuso y la recolección masiva de datos (farming) y como base de los planes de uso. También señala que las claves emitidas a clientes de terceros son relativamente fáciles de comprometer, y recomienda no depender exclusivamente de ellas para proteger recursos sensibles, críticos o de alto valor. OAuth 2.0 (RFC 6749, citada) resuelve un problema distinto: permitir que una aplicación de terceros acceda a los recursos de un usuario sin conocer su contraseña. La RFC enumera lo que falla al compartir contraseñas; por ejemplo, los propietarios de los recursos no pueden revocar el acceso de un tercero concreto sin revocar el de todos. Su flujo de concesión de código de autorización (authorization code grant) emite tokens de acceso con alcance limitado y tokens de actualización (refresh tokens); la RFC 6750 (citada) define cómo se presenta el bearer token resultante en el campo de cabecera de solicitud Authorization.

Por qué importa

Si se eligen claves para un caso de uso de acceso delegado, los usuarios se ven obligados a entregar sus credenciales, o una clave con todos los permisos, a los integradores. Si se elige OAuth para un integrador servidor a servidor sencillo, se añaden redirecciones y gestión de tokens que nadie necesita.

Cómo aplicarlo

• El integrador actúa en nombre propio (sus propios datos, facturación y cuotas): una clave de API, o la concesión de credenciales de cliente (client credentials grant) de OAuth si ya se dispone de un servidor de autorización.
• El integrador actúa en nombre de los usuarios del servicio: código de autorización de OAuth con alcances (scopes); los clientes nativos y las aplicaciones de una sola página (SPA) añaden PKCE.
• En cualquier caso: enviar las credenciales en una cabecera y nunca en la URL, ya que OWASP advierte de que las URL acaban en los registros; mostrar el secreto una sola vez al crearlo y almacenar solo su hash; permitir que los propietarios nombren, roten y revoquen cada credencial; responder 401 ante credenciales ausentes o no válidas y 403 cuando el alcance sea insuficiente.
• Dar a las claves un prefijo reconocible que codifique el tipo y el entorno, de modo que los escáneres puedan encontrar las claves filtradas y se puedan revocar.
• Aplicar límites de frecuencia (rate limiting) y auditoría por credencial, no por cuenta, para poder cortar el acceso de una integración comprometida sin afectar a las demás.

Trampas

Claves de larga duración y sin alcance limitado incrustadas en código de navegador. Servidores de recursos OAuth que validan el token pero omiten la comprobación del alcance. Tratar una clave como autenticación de una persona, cuando identifica a una aplicación. Implementar OAuth a partir de la RFC únicamente, en lugar de desplegar un servidor de autorización mantenido.