Seguridad de APIs para el CTO: identidad, gateway y tokens, sin confiar a ciegas

Una arquitectura de seguridad de APIs frecuente hoy tiene tres piezas: un proveedor de identidad que emite los tokens —Keycloak, Microsoft Entra ID, Okta u otro—, un gateway que recibe todo el tráfico —APISIX, Kong, Apigee, Azure API Management u otro— y OAuth 2.0 como el idioma con el que se piden y se presentan permisos. Es una buena arquitectura. El problema aparece en las preguntas que nadie escribió al diseñarla: ¿el servicio que está detrás del gateway vuelve a revisar el token? ¿Qué pasa cuando una API llama a otra? Si el usuario cierra sesión, ¿su token deja de servir? ¿Cuánto debe durar un token?

Este artículo responde esas preguntas para quien tiene que firmar la arquitectura: el CTO de un banco, una fintech, una aseguradora, una cadena de retail o cualquier empresa regulada. Cada respuesta viene con su condición, porque en seguridad casi nunca hay un «siempre».

Tres tipos de ruta, tres niveles de confianza

Antes de hablar de tokens, conviene clasificar cada ruta de la API:

Una API key identifica, pero no autoriza bien: no trae permisos finos, ni a quién va dirigida, ni vencimiento estándar, ni delegación [1][2]. Sirve para consumo simple, medición y cuotas. Para una integración entre empresas (B2B) con datos sensibles, conviene OAuth 2.0 con credenciales de cliente (client credentials): el sistema socio obtiene por API un token de vida corta, con permisos acotados y dirigido a su API [3][4]. Esa vía aplica cuando el sistema actúa por cuenta propia o bajo un acuerdo previo; no sustituye el consentimiento de una persona. Si conserva API keys: una por consumidor y por ambiente, guardadas como secreto, rotadas y nunca en la URL, porque las URL quedan escritas en las bitácoras del gateway, de los proxies y de las herramientas de monitoreo, donde cualquiera con acceso las puede leer [2].

¿El servicio detrás del gateway debe revisar el token?

Es la pregunta que más discusiones genera, y la respuesta corta es: estar detrás del gateway no da confianza por sí solo. Lo dice el marco de confianza cero del NIST: la ubicación en la red no implica confianza, y la zona de confianza implícita debe ser lo más pequeña posible [5].

La respuesta completa separa dos cosas que suelen confundirse:

• Validar el token (¿es auténtico, lo emitió mi proveedor, es para mí, sigue vigente?).
• Autorizar la operación (¿esta persona o este sistema puede leer esta cuenta, esta póliza, este pedido?).

La segunda, la autorización fina sobre el objeto, debe evaluarse donde estén disponibles la regla de negocio y la relación con el objeto: normalmente en el servicio o en un componente de política integrado a él. El gateway puede complementar con controles gruesos, pero no sustituye esa regla. Un permiso genérico como «leer pagos» no decide si alguien puede leer el pago de otro cliente. Ese error tiene nombre y es el primero de la lista de riesgos de APIs de OWASP [6][7].

La primera puede delegarse al gateway, pero solo si se cumplen todas estas condiciones [5][8][9]:

1. El servicio no es alcanzable por ningún otro camino que no sea el gateway: ni desde otra red, ni desde otro servicio vecino, ni por una ruta administrativa.
2. El canal entre el gateway y el servicio está autenticado, por ejemplo con TLS mutuo.
3. El gateway borra cualquier encabezado de identidad que llegue de fuera y pone el suyo, firmado (por ejemplo, un token interno) o sobre un canal autenticado, de modo que el servicio pueda verificar que viene del gateway.
4. La configuración de rutas está inventariada, se prueba y falla cerrada: una ruta sin regla no queda abierta.

Si una condición no se cumple, documente otro punto de aplicación de política que valide de forma verificable la identidad del llamador y el contexto; si no existe, el servicio deberá hacerlo. Y hay casos en que conviene que lo valide aunque se cumplan las cuatro: cuando maneja dinero o datos personales, cuando decide con datos del token, o cuando atiende a varios clientes o dominios.

Un detalle de configuración que vale oro: en algunos gateways, los plugins que validan API keys o JWT reenvían la credencial original al servicio de atrás salvo que se configure lo contrario, y el de OpenID Connect, con bearer_only en false, no exige estrictamente un token portador [10][11]. Son los valores documentados en APISIX 3.19 [proveedor]; confirme la versión instalada y la configuración efectiva. Revisar esos valores por defecto es parte de la arquitectura, no un detalle.

Cuando una API llama a otra

Dentro de la arquitectura, un servicio necesita llamar a otro. Hay cinco patrones frecuentes, y cada una sirve para algo distinto [12][13][14]:

Una regla que reduce el riesgo de reutilización indebida: cada servicio verifica que el token iba dirigido a él. El campo que lo dice se llama audiencia (aud), y si el servicio no está ahí, el token se rechaza [15][16]; para restringir el destino al pedirlo, existen los indicadores de recurso (RFC 8707) [30]. Así se evita el error de «reenviar a ciegas» (token passthrough) y su consecuencia más conocida, el confused deputy: un servicio que, con un token ajeno, hace algo que el usuario nunca autorizó. Por ejemplo, un servicio de reportes que recibe un token emitido para el servicio de pagos y, con él, termina pudiendo ejecutar pagos.

Para la cadena «A llama a B a nombre del usuario», el patrón recomendado es el intercambio de tokens: A cambia el token que recibió por uno nuevo, dirigido a B y con menos permisos [12]. En Keycloak, la función estándar V2 viene habilitada por defecto, pero el cliente solicitante debe ser confidencial y tener habilitado Standard token exchange; el intercambio estándar opera entre clientes del mismo realm [17]. Y el NIST propone algo parecido para microservicios: cambiar el token externo en la entrada por uno interno de vida corta, y verificarlo en cada salto [8].

¿Confiar en el token o preguntarle al proveedor?

Hay dos formas de saber si un token es bueno:

Validar localmente no es solo «la firma pasó»: hay que fijar el emisor esperado, aceptar solo los algoritmos previstos, revisar audiencia, vencimiento y permisos, y obtener las llaves de un lugar confiable, porque el proveedor las rota: el servicio guarda en caché las llaves públicas y, cuando llega un token firmado con una llave que no conoce, las vuelve a pedir en lugar de rechazarlo o de aceptarlo a ciegas [18][19]. Y un costo que el CTO firma: con introspección en cada petición, el proveedor de identidad queda en la ruta crítica de todas las operaciones; si se cae o se alenta, se cae o se alenta todo. Y si se guarda en caché el resultado de una introspección, el tiempo de caché no puede ser mayor que la ventana de revocación que el negocio acepta: una caché de cinco minutos contradice una promesa de revocación «inmediata».

Cerrar sesión no apaga los tokens ya emitidos

Un efecto operativo relevante, que suele sorprender a un comité de seguridad: cuando un usuario cierra sesión, el access token que ya tenía sigue siendo válido hasta que vence, para cualquier servicio que lo valide localmente. Los mecanismos de cierre de sesión de OpenID Connect terminan la sesión y avisan a las aplicaciones, pero no invalidan los access tokens que ya circulan [20][21]; la documentación de Keycloak lo advierte de forma explícita [17].

Por eso la vigencia se diseña en capas:

1. Access tokens cortos, para que la ventana de exposición sea chica.
2. Refresh tokens revocables, ligados al cliente y, en aplicaciones públicas, con rotación [3].
3. Introspección en las operaciones donde el estado actual importa: transferencias, cambios de beneficiario, descargas masivas, acciones administrativas.
4. Revocación (RFC 7009) cuando el proveedor la soporta [22].
5. Eventos de revocación entre sistemas (OpenID CAEP), que ya son estándar final; su soporte en los proveedores todavía es desigual [23].

¿Cuánto debe durar un token?

No existe una duración «estándar» en ninguna norma. OAuth deja la vida del token al proveedor [4]; el estándar de tokens portadores recomienda una hora o menos [24]; y el perfil de seguridad de la banca abierta (FAPI 2.0) pide tokens cortos sin fijar una cifra [25]. Lo que sí hay son rangos iniciales de diseño —criterio editorial, no una norma—; ajústelos a la exposición, la ventana de revocación, la reautenticación y la disponibilidad del proveedor:

Los valores de fábrica de Keycloak [proveedor] van en esa línea. Los verificamos directamente en su código fuente (rama principal consultada el 6-oct-2026), porque la documentación no los publica completos [26]. Son cifras del proveedor y pueden cambiar entre versiones:

En Keycloak, el refresh token de una sesión normal vive lo que la sesión permita. Antes de confiar en estos números, revise los de su instalación: los ajustes por cliente y las importaciones los cambian.

¿Cuándo hace falta OpenID Connect?

• OAuth 2.0 basta cuando lo que se protege es el acceso de una aplicación o un sistema a una API: integraciones entre empresas, procesos internos, permisos por alcance [4].
• OpenID Connect conviene cuando la aplicación necesita identidad autenticada interoperable, claims de autenticación o inicio de sesión único (también nivel de autenticación, cierre de sesión y reautenticación para acciones sensibles) [27]. OAuth por sí solo no estandariza esa identidad: OpenID Connect es la capa de identidad encima de OAuth.
• Un error frecuente: usar el ID token de OpenID Connect para llamar a una API. El ID token es para la aplicación que inició sesión; a la API se le manda el access token [27].

En banca abierta, la vara sube

Si su API cae en el mundo de la banca abierta o de datos financieros, el perfil FAPI 2.0 (estándar final) sube la vara: tokens atados a quien los usa —con TLS mutuo o DPoP—, autenticación fuerte del cliente y parámetros de la solicitud protegidos [25][28][29]. No es obligatorio para todas las APIs ni una obligación mexicana por sí mismo: puede ser una referencia técnica útil para APIs de alto valor cuando el marco aplicable, un contrato o la política de riesgo la adopten, y no sustituye la evaluación de las obligaciones regulatorias aplicables.

Por dónde empezar

1. Clasifique sus rutas en públicas, con API key y con token, y revise que cada una esté donde debe.
2. Decida, servicio por servicio, quién valida el token, con las cuatro condiciones de arriba por escrito.
3. Verifique la audiencia en cada servicio y elimine el reenvío de tokens a ciegas.
4. Revise los valores por defecto de su proveedor de identidad y de su gateway.
5. Defina su ventana de revocación por tipo de operación, y ajuste duraciones e introspección a ella.

¿Cuántas de sus rutas aguantarían hoy esa revisión? La primera conversación es sin costo: sale con el mapa de sus rutas por nivel de confianza y las brechas que conviene atender primero. Escríbanos por WhatsApp.