Sécurité API et tokens

Résumé succinct

La sécurité API est un ensemble de mécanismes d'authentification, d'autorisation, de protection cryptographique, d'anti-abus et d'observation qui assure que la requête exécute le sujet attendu vers la ressource attendue dans le contexte attendu. L'artefact clé est un jeton (ou une signature de demande) prouvant le droit d'appel. Une bonne architecture repose sur des jetons à courte durée de vie, des tampons clairs, des privilèges minimaux, une protection contre les répétitions, un taux de limitation et des procédures opérationnelles (rotations, audits, incidents).

Modèles d'authentification API : Quand et quoi choisir

Clé API (secret statique)

Simple pour les intégrations B2B et les scénarios à faible risque. Ne porte pas de contexte, nécessite un stockage côté service.
Utilisez uniquement avec IP/ASN allow-list, quotas fixes, TTL courts et rotations.

OAuth 2. 1 / OIDC

Standard pour les intégrations utilisateur et partenaire : access token (à courte durée de vie) + refresh token (rotation) + scoops.
Clients publics - avec PKCE ; clients confidentiels - avec le secret client/mTLS.

Client Credentials (m2m)

Mashina→mashina : access token pour les services sur des scoops et une audience strictement définis, souvent sans refresh (recover).

mTLS (réciproque TLS)

Lie l'identité au canal. Idéal pour les intégrations à haut risque ou de paiement (PoP sur TLS).
Peut être combiné avec OAuth (jetons uniquement pour les clients mTLS).

Signatures des demandes (HMAC/EdDSA)

Lorsque vous avez besoin d'un PoP indépendant des transports : titre de signature, timestamp et nonce. Pratique pour les webhooks et la vérification hors ligne.

Formats et types de tokens

JWT (JWS, signé)

Autosuffisants, testés localement ; sont obligatoires "iss'," sub "," aud "," bou "," iat "," jti "," scope ".
Risque - Les rappels sont plus complexes : utilisez des TTL courts (5-15 min) + une liste de « jti » rappelés en cas d'incident.

JWE (JWT crypté)

Nécessaire si payload sensible (PII). Coût - plus de complexité et de frais généraux.

Reference tokens

Les ID opaques sont vérifiés via l'introduction de l'Autorité Server - plus facile à rappeler/centraliser.

PoP/DPoP

Lier un token à une clé client ou à une session TLS réduit la valeur du token volé.

Contenu du token : minimum suffisant

• « iss' (issuer), » sub « (subject), » aud' (système/ressource cible), « bou » (terme), « iat », « nbf » (facultatif), « jti ».
• 'scope '/' permissions' (minimum nécessaire), 'tenant' (pour multitenants), 'device _ compliant '/' amr' (méthode d'authentification), 'ip '/' asn' (le cas échéant pour la politique).

• Court TTL pour l'accès (5-15 min), refresh - 12-48 h (avec rotation rotative).
• L'audience ("aud') est une ressource strictement spécifique, sinon le token est" réutilisable ".
• Scoops - action et objet (par exemple, 'payments : withdraw. read`).
• Taille - ≤ 2-4 Ko pour les titres et les proxy ; sinon, des problèmes de gateways sont possibles.

Autorisations et politiques

RBAC + ABAC : rôle + contexte (organisation, géo, risque, état du dispositif).
PEP/PDP : vérification du token et prise de décision sur la passerelle API/proxy (Envoy/OPA) avant l'application.
Règles déclaratives : Stockez dans Git, passez les tests politiques dans 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
}

Signature des requêtes (HMAC) et anti-replay

Au besoin : webhooks, intégration sans OAuth, double vérification des opérations critiques.

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))

• Refuser les requêtes avec le temps de résolution> ± 300 s.
• Nonce stocker 5-15 min et ne pas accepter les répétitions (replay-cache).
• Signer la représentation canonisée de la requête (méthode, chemin, query, hachage du corps).

Idempotence et protection transactionnelle

Idempotency-Key pour les opérations de débit/paiement/création : la même clé → le même effet.
La durée de vie de la clé est la durée ≥ du délai d'affaires (généralement 24-72 heures).
Logique côté serveur : comparer les paramètres de requête avec ceux précédemment fixés pour cette clé.

Navigateurs et clients mobiles

PKCE est obligatoire (clients publics).
Le token Refresh dans le navigateur est à éviter ; Si nécessaire - ROTATION + réponse à la répétition (replay-detect).
Stockage : Session storage> local storage ; mieux - backend for frontend (BFF) est responsable des tokens.
SameSite, Secure, HttpOnly для cookie; CORS - listes explicites, titres et méthodes ; preflight-cache en toute sécurité.

m2m et intégrations à haut risque

mTLS + OAuth2 Client Credentials avec scoops et 'aud'.
IP/ASN allow-list sur le gateway.
PoP/DPoP ou signature HMAC au-dessus de TLS pour les opérations critiques.
Quotas et limites de taux par organisation/client/clé.

Rotations, rappels et interventions en cas d'incident

Rotation des secrets et des clés de signature (JWKS) : programmé + forcé en cas d'incident.
Double-clé rollout : publiez une nouvelle paire de clés à l'avance (kid2), signez-lui des jetons, gardez l'ancienne (kid1) pour la validation jusqu'à épuisement de la TTL.
Refresh-rotation : chaque échange de refresh → un nouveau jeton, l'ancien devient immédiatement invalide ; la répétition est un signal de compromission.
Revocation : Pour JWT, des listes de « jti » retirées pour une courte période ; pour les tokens de référence - verrouillage immédiat sur AS.
Scripts break-glass : crédits statiques temporaires avec un minimum de droits et un TTL dur, enregistrez-le dans le journal.

Limitation des taux, protection contre le bot et protection contre la surexploitation

Limites à trois couches : per-key/per-IP/per-organization.
Burst + sustained : jeton-réservoir/fenêtre coulissante.
Contrôles complexes : device fingerprint, signaux comportementaux, anomalies geo/ASN, CAPTCHA uniquement pour l'IU.
Lockout/slowdown en cas de dépassement de signature/NMAS et de tentatives d'authentification échouées.

Logging, métriques et SLO

Jeu minimum de logs : 'request _ id',' client _ id ',' sub ',' aud ',' scope ',' decision ',' reason ',' jti ',' ip ',' asn ',' latency ',' quota _ state '.

• Succès de la validation des tokens (%), p95 temps de vérification.
• Taux d'anomalies de replay, doublons Idempotency-Key.
• Proportion de requêtes avec PoP/DPoP/mTLS.
• Erreurs 'aud/scope'qui ont expiré 'bou', décalage temporel (NTP).

• Disponibilité Auth/AS ≥ 99. 95 %/mois ; p95 introspection ≤ 50 мс.
• Zéro tokens avec TTL <60 c dans la vente (métrique de sécurité).
• Moins de 0. 1 % d'erreurs 'aud/scope' par jour (qualité des intégrations).

Exemples de configuration

Envoy : vérification JWT et audience

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;

Exemple de titre de signature (webhooks)

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

Le serveur rejette si 't'est supérieur à 300 c,' n'a déjà rencontré, ou si 's'ne bat pas.

Protection des données et vie privée

Minimisez les stigmates (en particulier les PII) et la durée de vie.
Crypter les marques sensibles (JWE) pour les intégrations tierces.
Mask/DLP dans les logs : ne pas loger les corps avec PAN/PII, les tokens ne sont que des « kid »/drapeaux, pas un secret.

Erreurs typiques

Jetons d'accès longs et refresh « éternel ».
L'absence de 'aud'/' scope' → les jetons sont polyvalents.
Signature de webhooks sans 'timestamp '/' nonce'.
Vérifiez JWT uniquement dans l'application et non sur le gateway (PEP).
Pas de rotation et double clé rollout.
CORS « » et les méthodes dangereuses autorisées sans contrôle des titres.
Stockez des tokens dans 'localStorage' sans BFF.

Feuille de route pour la mise en œuvre

1. Inventaire des IPA et classification (public/partenaire/interne, sensibilité).
2. Sélection du modèle AuthN : OAuth2/OIDC pour l'utilisateur, mTLS + Client Credentials/HMAC pour m2m.
3. Tokens : court TTL, strict "aud', scoops, DPoP/PoP pour les opérations critiques.
4. PEP sur le gateway : validation JWT, signatures et limites de taux avant l'application.
5. Anti-replay et idempotence : timestamp/nonce/Idempotency-Key.
6. Rotations et JWKS : double clé, automatisation et alerting.
7. Observabilité : métriques/SLO, journaux d'accès, signaux UEBA.
8. Exercices : Clé de signature, fuite de refresh, surcharge de quotas.

Spécificité pour iGaming/fintech

Paiements/décaissements : seulement mTLS + PoP/HMAC, scoops stricts ('withdraw. create '), idempotency est obligatoire.
Partenaires (PSP/fournisseurs de contenu) : clés/certificats per-partner, IP/ASN allow-list, quotas séparés et dashboards.
GDPR/PCI DSS : minimisation des marques, interdiction des PII dans les tokens tiers, logigation de l'accès aux ressources sensibles, examen régulier de l'accès.
Anti-abuse : limites comportementales, géo-contrôle, protection contre les bonus-abuses au niveau API.

FAQ

JWT ou référence token ?
JWT - performance et autonomie ; référence - rappel centralisé et facilité d'intervention. Souvent hybride : externe - JWT, interne - référence.

Ai-je besoin de JWE ?
Seulement si payload contient PII/secrets. Sinon, JWS avec un minimum de marques.

Puis-je vivre avec des clés API ?
Oui, mais seulement avec une TTL courte, des quotas stricts, une liste IP-allow et la signature des demandes. Pour les utilisateurs - de préférence OAuth/OIDC.

DPoP/PoP obligatoire ?
Pas toujours. Mais pour les transactions à risque élevé (paiements, conclusions) - très souhaitable.

Résultat

La sécurité robuste de l'API repose sur des tokens à courte durée de vie, des échantillons précis et un public, des canaux sécurisés (TLS/mTLS), la signature de requêtes et une protection anti-replay stricte, renforcée par les limites et l'observabilité. Ajoutez des rotations automatisées, des rollout dual-key et des contrôles politiques sur les gateways - et votre API sera résistante aux fuites, aux répétitions et aux abus, tout en conservant des performances et une gestion élevées.