Verify API Key vs OAuth v2

Verify API Key o OAuth v2: cuál usar y cuándo en SAP API Management

Una de las primeras decisiones técnicas en cualquier proyecto de SAP Integration Suite es esta: ¿cómo asegurar el acceso a las APIs que vamos a exponer? La plataforma ofrece varios mecanismos, pero el dilema casi siempre se reduce a dos: Verify API Key u OAuth v2. Ambas funcionan, ambas son políticas estándar del API Proxy y ambas resuelven el mismo problema en apariencia. La diferencia está en la letra pequeña, y esa letra pequeña marca cómo será el mantenimiento de la API durante los próximos años.

En este artículo vemos cómo funciona cada una, qué necesita el consumidor en cada caso, cuándo merece la pena el coste extra de OAuth y cuándo basta con una API Key. Sin recetas mágicas: criterios concretos y un árbol de decisión al final.

Verify API Key: el camino corto

Verify API Key es la política más utilizada en escenarios reales de SAP API Management por una razón muy sencilla: funciona y se configura en cinco minutos. La idea es directa.

Cuando publicas una API en el Developer Hub, los consumidores se registran y crean una aplicación. Esa aplicación recibe un par de credenciales: una Consumer Key (la API Key propiamente dicha) y un Consumer Secret. La aplicación incluye la API Key en cada petición, normalmente como cabecera HTTP o como query parameter. El API Proxy, gracias a la política Verify API Key, valida que esa clave existe, está activa y tiene permiso para consumir el producto al que pertenece la API.

Verify API Key valida la clave contra el Developer Hub en un único paso del flujo.

Lo que esto te da en la práctica:

• Identifica la aplicación, no al usuario. Sabes qué partner o qué app está llamando, pero no qué persona concreta está detrás del clic.
• Permite aplicar Quota por aplicación. Cada plan del Developer Hub puede tener su propio límite y se controla con esa misma clave.
• La revocación es inmediata. Si una clave se filtra, la invalidas en el Developer Hub y deja de funcionar al instante.
• No requiere un servidor de autorización adicional. Todo vive dentro de SAP API Management.

OAuth v2: el estándar cuando el contexto importa

OAuth v2 resuelve un problema distinto. No es solo “validar al que llama”, es “validar al que llama, en nombre de quién llama, para qué recurso y durante cuánto tiempo”. Por eso es más complejo, y también por eso es el estándar de facto para APIs expuestas a internet o cuando hay un Identity Provider corporativo en medio.

El flujo más habitual en SAP es Client Credentials: la aplicación cliente intercambia un client_id y un client_secret contra un Authorization Server (típicamente SAP XSUAA en BTP o SAP IAS en escenarios federados) y recibe un access token en formato JWT, válido durante un tiempo limitado. Cada llamada posterior a la API lleva ese token en la cabecera Authorization: Bearer. El proxy, gracias a la política OAuth v2, verifica la firma del token, su expiración y los scopes antes de dejarlo pasar al backend.

En OAuth v2 hay dos viajes: primero se negocia el token con el Authorization Server y después se llama a la API con ese token.

Las ventajas que tiene sobre Verify API Key son concretas:

• Tokens de corta duración. Aunque alguien intercepte un token, su ventana de uso está limitada por la propia expiración.
• Renovación automática. El cliente pide un nuevo token sin intervención humana cuando el actual caduca.
• Permite delegación. En grant types como Authorization Code, el token representa a un usuario final concreto, no solo a la aplicación.
• Encaja con el modelo de seguridad de SAP BTP. XSUAA y IAS están pensados desde el primer minuto para hablar OAuth con los servicios de la plataforma.

La contrapartida es el coste de implantación: hay que configurar el Authorization Server, registrar la aplicación cliente, gestionar los scopes y, sobre todo, entender bien qué grant type aplica a cada escenario. No es trivial la primera vez.

Comparativa: lo que cambia en la práctica

Resumimos en una tabla las diferencias que importan a la hora de decidir.

Mismos objetivos, perfiles de uso distintos.

¿Cuándo usar cada una?

Dos preguntas suelen ser suficientes para elegir sin titubear.

Errores comunes en cada elección

Usar Verify API Key cuando hay usuarios finales.
Si tu API necesita aplicar autorizaciones distintas según quién consulte, la API Key no te sirve: identifica la app, no la persona. Tarde o temprano vas a tener que reescribir el proxy con OAuth y migrar a los consumidores. Es mejor asumir el coste al principio.

Implantar OAuth porque “queda más serio”.
Para una API interna que solo van a consumir tres procesos automatizados de tu propia empresa, OAuth añade complejidad sin un beneficio claro. La sobreingeniería tiene un coste real en mantenimiento.

No combinar las dos políticas con otras.
Tanto Verify API Key como OAuth v2 solo verifican la credencial. Ninguna controla volumen de tráfico, ninguna transforma el payload, ninguna registra el consumo. Combínalas siempre con Quota, Spike Arrest y, si procede, Message Logging.

Devolver el error de autenticación tal cual.
Cuando una clave o token falla, el cliente no debería ver el detalle interno del proxy. Captura el fallo con un FaultRule, devuelve un 401 limpio con un mensaje claro y deja la traza completa en los logs del lado del Gateway.

Conclusión

No hay una respuesta única a “¿API Key u OAuth?”. Hay un conjunto de preguntas que llevan a la elección correcta: ¿quién consume?, ¿desde dónde?, ¿necesito identidad de usuario?, ¿cuánto puedo invertir en el setup inicial? Si te identificas más con escenarios internos o B2B controlados, Verify API Key es suficiente y te ahorra trabajo. Si vas a abrir APIs al exterior o necesitas delegación de identidad, OAuth v2 es el camino.

Lo importante es tomar la decisión de forma consciente, no por inercia ni por copia de un proyecto anterior. El modelo de seguridad de una API marca su ciclo de vida completo: cómo se documenta, cómo se onboardean los consumidores y cómo se monitoriza el consumo. Conviene elegirlo bien desde el primer diseño.