Seguridad de API y tokens

Resumen breve

La seguridad de la API es un conjunto de mecanismos de autenticación, autorización, protección criptográfica, anti-abuso y vigilancia que asegura que la solicitud ejecuta el sujeto esperado al recurso esperado en el contexto esperado. Un artefacto clave es un token (o firma de solicitud) que acredita la elegibilidad para una llamada. La buena arquitectura se basa en tokens de vida corta, scoups claros, privilegios mínimos, protección contra repeticiones, rating limiting y procedimientos operativos (rotaciones, auditorías, incidentes).

Modelos de autenticación de API: cuándo y qué elegir

Clave API (secreto estático)

Fácil para integraciones B2B y escenarios de bajo riesgo. No lleva contexto, requiere almacenamiento en el lado del servicio.
Utilice sólo con IP/ASN allow-list, cuotas fijas, TTL cortas y rotaciones.

OAuth 2. 1 / OIDC

Estándar para integraciones de usuarios y socios: access token (short-short) + refresh token (rotation) + scope.
Clientes públicos - con PKCE; clientes confidenciales: con el secreto del cliente/mTLS.

Client Credentials (m2m)

Mashina→mashina: access token para servicios por scoups estrictamente especificados y audience, a menudo sin refresh (obtener de nuevo).

mTLS (TLS mutuo)

Vincula la identidad a un canal. Ideal para integraciones de alto riesgo o pago (PoP sobre TLS).
Puede combinarse con OAuth (tokens sólo para clientes mTLS).

Firmas de solicitud (HMAC/EdDSA)

Cuando se necesita un PoP independiente del transporte: título de firma, timestamp y nonce. Conveniente para webhooks y la verificación fuera de línea.

Formatos y tipos de tokens

JWT (JWS firmados)

Autosuficiente, verificado localmente; obligatoriamente 'iss',' sub ',' aud ',' amb ',' iat ',' jti ',' scope '.
Riesgo - La revisión es más difícil: use TTL cortos (5-15 min) + lista de revocados 'jti' en incidentes.

JWE (JWT cifrado)

Es necesario si el payload es sensible (PII). Costo - mayor complejidad y gastos generales.

Reference tokens

Identificadores opacos, validados a través de la introspección en Authorization Server - más fácil revocación/centralización.

PoP/DPoP

Vincular un token a una clave de cliente o a una sesión TLS reduce el valor del token robado.

Contenido del token: mínimo suficiente

• 'iss' (issuer), 'sub' (subject), 'aud' (target system/resource), 'exp' (término), 'iat', 'nbf' (opcional), 'jti'.
• 'scope '/' permissions' (mínimo necesario),' tenant '(para multitenantes),' device _ compliant '/' amr '(método de autenticación),' ip '/' asn' (si se aplica a la política).

• TTL corto para acceso (5-15 min), refresh - 12-48 h (con rotación giratoria).
• El público ('aud') es un recurso estrictamente específico, de lo contrario el token es «reutilizable».
• Scoups: acción y objeto (por ejemplo, 'payments: withdraw. read`).
• Tamaño - ≤ 2-4 KB para encabezados y proxy; de lo contrario, los problemas con los gateways son posibles.

Autorización y políticas

RBAC + ABAC: rol + contexto (organización, geo, riesgo, estado del dispositivo).
PEP/PDP: valide el token y decida en la puerta de enlace/proxy de la API (Envoy/OPA) antes de la aplicación.
Reglas declarativas: almacenar en Git, pasar las pruebas de políticas en CI.

rego package policy. withdraw

default allow = false

allow {
input. token. aud == "wallet-api"
input. token. scope[_] == "payments:withdraw. create"
input. device. compliant == true input. risk. score < 70
}

Firma de solicitud (HMAC) y anti-respuesta

Cuando sea necesario: webhooks, integraciones sin OAuth, doble verificación de operaciones críticas.

X-Client-Id: <id>
X-Timestamp: 2025-11-05T13:20:10Z
X-Nonce: 4d1f...a2
X-Signature: base64(HMAC_SHA256(secret, method + "\n" + path + "\n" + sha256(body) + "\n" + timestamp + "\n" + nonce))

• Rechazar solicitudes con tiempo de rissincrono> ± 300 p.
• Nonce almacenar 5-15 min y no tomar repeticiones (replay-cache).
• Firmar la representación canonizada de la consulta (método, ruta, query, hash del cuerpo).

Idempotencia y protección transaccional

Idempotency-Key para operaciones de cobro/pago/creación: la misma clave → el mismo efecto.
La vida útil de la llave es el tiempo ≥ del tiempo de espera de negocios (generalmente 24-72 h).
Lógica en el lado del servidor: compare la configuración de la consulta con las configuraciones previamente fijadas para esta clave.

Clientes de navegador y móviles

PKCE es obligatorio (clientes públicos).
Refresh-token en el navegador - evitar; si es necesario - ROTATION + respuesta a la repetición (replay-detect).
Almacenamiento: almacenamiento de sesión> almacenamiento local; mejor - los tokens son responsables de backend for frontend (BFF).
SameSite, Secure, HttpOnly для cookie; CORS - allow-lists explícitos, encabezados y métodos; preflight-caché seguro.

m2m e integraciones de alto riesgo

mTLS + OAuth2 Credentials Client con Scoups y 'aud'.
IP/ASN allow-list en la gateway.
Firma PoP/DPoP o HMAC sobre TLS para operaciones críticas.
Cuotas y rate limits por organización/cliente/clave.

Rotaciones, revocaciones y respuesta a incidentes

Rotación de secretos y claves de firma (JWKS): programada + forzada en un incidente.
Dual-key rollout: publica un nuevo par de claves por adelantado (kid2), firma los tokens de ella, guarda el antiguo (kid1) para validarlo hasta que se agote el TTL.
Refresh-rotation: cada intercambio de refresh → un nuevo token, el antiguo se invalida inmediatamente; repetición - señal de compromiso.
Revocación: para JWT - listas de revocados 'jti' por un corto período; para reference tokens - bloqueo inmediato en AS.
Scripts break-glass: créditos estáticos temporales con derechos mínimos y TTL rígidos, registre.

Rate limiting, bot-protection y protección contra sobrecarga

Límites de tres capas: per-key/per-IP/per-organization.
Burst + sustained: token-back/ventana deslizante.
Comprobaciones complejas: device fingerprint, señales de comportamiento, anomalías geo/ASN, CAPTCHA solo para IU.
Lockout/slowdown cuando la firma/NMAS se sobreescribe e intentos de autenticación fallidos.

Lógica, métricas y SLO

Conjunto mínimo de registros: 'request _ id', 'client _ id', 'sub', 'aud', 'scope', 'decision', 'reason', 'jti', 'ip', 'asn',' latency ',' quota _ state '.

• Éxito de validación de tokens (%), tiempo de verificación p95.
• Frecuencia de las desviaciones de respuesta, duplicados de Idempotency-Key.
• Porcentaje de solicitudes con PoP/DPoP/mTLS.
• Errores 'aud/scope' que han caducado 'amb', cambios de tiempo (NTP).

• Disponibilidad Auth/AS ≥ 99. 95 %/mes; p95 introspection ≤ 50 мс.
• Cero tokens con TTL <60 c en venta (métrica de seguridad).
• Menos de 0. 1% de errores 'aud/scope' por día (calidad de las integraciones).

Ejemplos de configuración

Envoy: verificación de JWT y audiencia

yaml http_filters:
- name: envoy. filters. http. jwt_authn typed_config:
providers:
as:
issuer: https://auth. example. com/
audiences: ["wallet-api"]
remote_jwks:
http_uri:
uri: https://auth. example. com/.well-known/jwks. json cluster: jwks_cluster cache_duration: 600s rules:
- match: { prefix: "/v1/withdraw" }
requires:
provider_and_audiences:
provider_name: as audiences: ["wallet-api"]

NGINX: mTLS к backend

nginx proxy_ssl_server_name on;
proxy_ssl_name wallet. internal;
proxy_ssl_certificate   /etc/nginx/mtls/client. crt;
proxy_ssl_certificate_key /etc/nginx/mtls/client. key;
proxy_ssl_trusted_certificate /etc/nginx/mtls/ca. crt;
proxy_ssl_verify on;
proxy_ssl_verify_depth 2;

Título de ejemplo de firma (webhooks)

X-Signature: t=1730803210,n=ac12...,s=base64(HMAC_SHA256(secret, "POST\n/webhook\nsha256(body)\n1730803210\nac12..."))

El servidor rechaza si 't' es mayor de 300 c, 'n' ya se ha encontrado, o' s' no pega.

Protección de datos y privacidad

Minimice los estigmas (especialmente PII) y la vida útil.
Cifre los sellos sensibles (JWE) para integraciones de terceros.
Mask/DLP en los logs: no lógica cuerpos con PAN/PII, los tokens son sólo 'kid '/banderas, no el secreto en sí.

Errores

Tokens de acceso de larga duración y refresh «eterno».
La ausencia de 'aud '/' scope' → los tokens son polivalentes.
Firma de webhooks sin 'timestamp '/' nonce'.
Comprobar JWT sólo en la aplicación, no en la gateway (PEP).
Falta de rotaciones y rollo dual-key.
CORS «» y técnicas inseguras resueltas sin control de cabecera.
Almacenar tokens en 'localStorage' sin BFF.

Hoja de ruta para la

1. Inventario de API y clasificación (público/afiliado/interno, sensibilidad).
2. Selección del modelo AuthN: OAuth2/OIDC para usuarios, mTLS + Clientes Credentials/HMAC para m2m.
3. Tokens: TTL cortos, estrictos 'aud', scopes, DPoP/PoP para operaciones críticas.
4. PEP en la gateway: validación de JWT, firmas y rating limits a la aplicación.
5. Anti-replay e idempotencia: timestamp/nonce/Idempotency-Key.
6. Rotaciones y JWKS: dual-key, automatización y alerting.
7. Observabilidad: métricas/SLO, registros de acceso, señales UEBA.
8. Las doctrinas: otozv de la llave de la firma, el derrame refresh, el transbordo de las cuotas.

Especificidad para iGaming/fintech

Pagos/pagos: sólo mTLS + PoP/HMAC, escopetas estrictas ('withdraw. create '), la idempotencia es obligatoria.
Partners (PSP/proveedores de contenido): claves/certificados per-partner, IP/ASN allow-list, cuotas individuales y dashboards.
GDPR/PCI DSS: minimización de los estigmas, prohibición de PII en tokens de terceros, lógica de acceso a recursos sensibles, revisión regular de acceso.
Anti-abuse: límites de comportamiento, control geo, protección contra bonus-abius a nivel API.

FAQ

¿JWT o reference token?
JWT - Rendimiento y autonomía; reference - retroalimentación centralizada y simplicidad del incidente-reacción. A menudo híbrido: externo - JWT, interno - referencia.

¿Necesita JWE?
Sólo si payload contiene PII/secretos. De lo contrario - JWS con los estigmas mínimos.

¿Puedo vivir con las claves de la API?
Sí, pero sólo con una TTL corta, cuotas estrictas, lista IP-allow y firma de solicitudes. Para los usuarios - preferiblemente OAuth/OIDC.

¿DPoP/PoP es obligatorio?
No siempre. Pero para operaciones de alto riesgo (pagos, retiros) es extremadamente deseable.

Resultado

La seguridad confiable de la API se basa en tokens de vida corta, scoups precisos y audiencias, canales seguros (TLS/mTLS), firmas de consulta y protección anti-replay estricta reforzada con límites y observabilidad. Agregue rotaciones automatizadas, dual-key rollout y control político en sus gateways, y su API se volverá resistente a fugas, repeticiones y abusos, mientras mantiene un alto rendimiento y manejabilidad.