Securitate API și jetoane

Scurt rezumat

Securitatea API este o colecție de autentificare, autorizare, protecție criptografică, anti-abuz și mecanisme de observabilitate care asigură că o cerere execută o entitate așteptată la o resursă așteptată într-un context așteptat. Artefactul cheie este un token (sau semnătură cerere) care dovedește dreptul de a apela. O arhitectură bună se bazează pe jetoane de scurtă durată, scopuri clare, privilegii minime, protecție de reluare, limitarea ratei și proceduri operaționale (rotații, audituri, incidente).

Modele de autentificare API - Când și ce să alegeți

Tasta API (secret static)

Simplu pentru integrarea B2B și scenarii cu risc scăzut. Nu poartă context, necesită depozitare pe partea de service.
Utilizați numai cu IP/ASN allow-list, cote fixe, TTL scurt și rotații.

OAuth 2. 1/OIDC

Standard pentru integrarea utilizatorilor și partenerilor: access token (pe termen scurt) + refresh token (rotație) + scopes.
Clienti publici - cu PKCE; clienti confidentiali - cu client secret/mTLS.

Acreditările clientului (m2m)

Mashina→mashina: access token pentru servicii pe domenii strict definite și audiență, adesea fără reîmprospătare (get again).

mTLS (TLS reciproc)

Leagă identitatea de canal. Ideal pentru integrarea de mare risc sau de plată (PoP peste TLS).
Poate fi combinat cu OAuth (token-uri numai pentru clienții mTLS).

Solicitați semnături (HMAC/EdDSA)

Când aveți nevoie de un PoP independent de transport: antet de semnătură, marcaj temporal și nonce. Convenabil pentru cârlige web și verificare offline.

Formate și tipuri de token

JWT (JWS, semnat)

Autosuficient, verificat local; obligatoriu "iss'," sub "," aud "," exp "," iat "," jti "," scope ".
Risc - rechemare mai dificil: utilizați scurt TTL (5-15 min) + lista de „jti” rechemat în incidente.

JWE (JWT criptat)

Necesar dacă sarcina utilă este sensibilă (PII). Cost - complexitate mai mare și deasupra capului.

Jetoane de referință

Identificatori opaci, verificați prin introspecție de către Authorization Server - rechemare/centralizare mai ușoară.

PoP/DPoP

Legarea unui jeton de o cheie client sau de o sesiune TLS reduce valoarea tokenului furat.

Conținut Token: Minim Suficient

Timbre recomandate (JWT):

"iss' (emitent)," sub "(subiect)," aud "(sistem ţintă/resursă)," exp "(termen)," iat "," nbf "(opţional)," jti ".
"scope "/" permisiuni" (minim necesar), "chiriaș" (pentru multi-chiriaș), "device _ compatibil "/" amr" (metoda de autentificare), "ip "/" asn' (dacă este cazul politicii).

Reguli:

Scurt TTL pentru acces (5-15 min), reîmprospătare - 12-48 h (cu rotație rotativă).
Publicul („aud”) este o resursă strict specifică, altfel tokenul este „reutilizabil”.
Scopuri - acțiune și obiect (de exemplu, "plăți: retragere. citește ").
Dimensiune - ≤ 2-4 KB pentru antete și proxy-uri; în caz contrar, pot exista probleme cu gateway-uri.

Autorizatie si Politici

RBAC + ABAC: rol + context (organizare, geo, risc, stare dispozitiv).
PEP/PDP Validarea Token și Decizia privind API Gateway/Proxy (Envoy/OPA) înainte de aplicare.
Reguli declarative: stocați în Git, treceți testele de politică în CI.

Exemplu rego (simplificat):

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
}

Semnarea cererii (HMAC) și anti-reluare

Atunci când este necesar: broșuri web, integrare fără OAuth, verificarea dublă a operațiunilor critice.

Schema antetului (exemplu):


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

Reguli:

Respingeți cererile cu alinierea greșită a timpului> ± 300 s.
Nonce stoca timp de 5-15 minute și nu acceptă reluări (cache reluare).
Semnați o vizualizare interogare canonizată (metodă, cale, interogare, hash corp).

Identitate și protecție tranzacțională

Idempotency-Key for write-off/pay-out/create operations: aceeași cheie → același efect.
Durata de viață cheie este timpul ≥ de afaceri (de obicei 24-72 de ore).
Logica serverului - Comparați parametrii de interogare cu cei angajați anterior pentru această cheie.

Browser și clienți de telefonie mobilă

PKCE este obligatorie (clienți publici).
Actualizați jetonul în browser - evitați; dacă este necesar - ROTATION + răspuns reluare (reluare-detectare).
Stocare: stocare sesiune> stocare locală; mai bine - backend pentru frontend (BFF) este responsabil pentru jetoane.
SameSite, Secure, HttpOnly для cookie; CORS - liste de permise, antete și metode explicite; verificarea cache-ului este sigură.

m2m și integrări cu risc ridicat

mTLS + OAuth2 Acreditările clienților cu scopuri și 'aud'.
IP/ASN permite-lista de pe poarta de acces.
PoP/DPoP sau semnături HMAC peste TLS pentru operațiuni critice.
Cote și limite de rată per organizație/client/cheie.

Rotații, rechemări și răspuns incident

Rotație cheie secretă și semnătură (JWKS): programată + aplicată pe incident.
Rollout cu două taste: publicați o nouă pereche cheie în avans (kid2), semnați jetoanele pentru ea, păstrați-l pe cel vechi (kid1) pentru validare până când TTL este epuizat.
Reîmprospătare-rotație: fiecare schimb de reîmprospătare → un nou token, cel vechi devine imediat invalid; repeta - semnal de compromis.
Revocare: pentru JWT - liste de „jti” rechemat pentru o perioadă scurtă de timp; pentru tokenurile de referință - blocare imediată pe AS.
Scripturi break-glass: credite statice temporare cu drepturi minime și TTL hard, record în jurnal.

Limitarea ratei, protecția bot și protecția forței brute

Limite de trei straturi: per-cheie/per-IP/per-organizare.
Explozie + susținută: token-tank/fereastră glisantă.
Verificări complexe: amprenta dispozitivului, semnale comportamentale, anomalii geo/ASN, CAPTCHA numai pentru UI.
Blocarea/încetinirea la renegocierea semnăturii/NMAC și încercările de autentificare eșuează.

Logare, măsurători și SLO

Setul minim de jurnale: 'request _ id',' client _ id', 'sub', 'aud', 'scope', 'decision', 'reason', 'jti', 'ip', 'asn',' latency ',' cota _ state '.

Măsurători:

Succes validare token (%), timp de verificare p95.
Frecvența de abateri de reluare, duplicate de Idempotency-Key.
Procentul de cereri cu PoP/DPoP/mTLS.
„aud/scope” erori, expirate „exp”, schimburi de timp (NTP).

SLO (exemple):

Auth/AS ≥ 99 disponibilitate. 95 %/lună; p95 introspecţie ≤ 50 мс.
Zero jetoane cu TTL <60 s în prod (metric de pază).
Mai puţin de 0. 1% din „aud/scopuri” erori pe zi (calitatea integrărilor).

Exemple de configurare

Trimisul: JWT și verificarea audienței

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;

Exemplu de antet de semnătură (cârlige web)


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

Serverul respinge dacă „t” este mai vechi de 300 c, „n” a întâlnit deja sau „s” nu bate.

Protecția datelor și confidențialitate

Minimizați semnele distinctive (în special PII) și durata de viață.
Criptați ștampilele sensibile (JWE) pentru integrările terților.
Mască/DLP în jurnale: nu înregistrați corpuri cu PAN/PII, token-uri - numai „copil ”/steaguri, nu secretul în sine.

Erori comune

Jetoane de acces cu durată lungă de viață și refresh „etern”.
Absența jetoanelor „aud ”/„ scopului” → sunt multifuncționale.
Semnătura cârligelor web fără „timestamp ”/„ nonce”.
Verificarea JWT numai în aplicație, nu pe poarta de acces (PEP).
Fără rotaţii şi cu două taste.
„CORS” și a permis metode nesigure, fără control antet.
Stocarea token-urilor în 'LocalStorage' fără BFF.

Foaie de parcurs pentru implementare

1. Inventarul și clasificarea API (public/partener/intern, sensibilitate).
2. Selectarea modelului AuthN: OAuth2/OIDC pentru custom, mTLS + Client Acreditări/HMAC pentru m2m.
3. Jetoane: scurt TTL, strict „aud”, scopuri, DPoP/PoP pentru operațiuni critice.
4. PEP pe gateway-uri: validare JWT, semnături și limite de rată pentru aplicație.
5. Anti-reluare și idempotență: timestamp/nonce/Idempotency-Key.
6. Rotații și JWKS: dual-cheie, automatizare și alertare.
7. Observabilitate: metrici/SLO, jurnale de acces, semnale UEBA.
8. Exerciții: cheie de semnătură, scurgere de reîmprospătare, suprasarcină de cotă.

Specificitate pentru iGaming/fintech

Plăți/plăți: mTLS + numai PoP/HMAC, scopuri stricte ('retrage. creați "), idempotența este necesară.
Parteneri (furnizori PSP/conținut): chei/certificate per partener, IP/ASN allow-list, cote individuale și tablouri de bord.
GDPR/PCI DSS: minimizarea ștampilelor, interzicerea PII în jetoane terțe, logarea accesului la resurse sensibile, revizuirea regulată a accesului.
Anti-abuz: limite comportamentale, geo-control, protecție împotriva abuzului de bonus la nivelul API.

ÎNTREBĂRI FRECVENTE

JWT sau token de referință?
JWT - performanță și autonomie; referință - feedback centralizat și simplitatea reacției la incidente. Adesea un hibrid: extern - JWT, intern - de referință.

Este nevoie de JWE?
Numai dacă sarcina utilă conține PII/secrete. În caz contrar - JWS cu semnele distinctive minime.

Pot trăi pe chei API?
Da, dar numai cu o scurtă TTL, cote stricte, IP-allow-list și semnarea cererii. Pentru utilizatori, se preferă OAuth/OIDC.

DPoP/PoP obligatoriu?
Nu întotdeauna. Dar pentru operațiunile cu risc ridicat (plăți, concluzii) este foarte de dorit.

Total

Securitatea API fiabilă este construită pe jetoane de scurtă durată, scopuri și audiențe exacte, canale securizate (TLS/mTLS), semnarea cererii și protecție strictă anti-reluare, îmbunătățită de limite și observabilitate. Adăugați rotații automate, rollout cu două taste și control politic pe gateway-uri - iar API-ul va fi rezistent la scurgeri, reluări și abuzuri, menținând în același timp performanța ridicată și capacitatea de administrare.