Protezione API e token

Breve riepilogo

La sicurezza dell'API è un insieme di meccanismi di autenticazione, autorizzazione, protezione crittografica, anti-abuso e osservabilità che garantiscono che la richiesta soddisfi l'obiettivo previsto per la risorsa prevista nel contesto previsto. L'artefatto chiave è un token (o una firma di query) che dimostra il diritto di chiamata. La buona architettura si basa su token a breve vita, scatti chiari, privilegi minimi, protezione contro le ripetizioni, rate limiting e procedure operative (rotazioni, verifiche, incidenti).

Modelli di autenticazione API quando e cosa scegliere

Chiave API (segreto statico)

Semplice per integrazioni B2B e script a basso rischio. Non contiene un contesto, richiede l'archiviazione sul lato del servizio.
Usa solo IP/ASN allow-list, quote fisse, TTL corto e rotazioni.

OAuth 2. 1 / OIDC

Standard per le integrazioni utente e partner: access token + refresh token (rotazione) + scoop.
Client pubblici - con PKCE; client confidential - con un segreto client/mTLS.

Client Credentials (m2m)

Mashina→mashina: access token per servizi rigorosamente definiti e udienze, spesso senza rifresh (ricezione).

mTLS (TLS reciproco)

Aggancia l'identità al canale. Ideale per le integrazioni a alto rischio o di pagamento (PoP su TLS).
Può essere combinato con OAuth (token solo per client mTLS).

Firme query (HMAC/EdDSA)

Quando hai bisogno di una firma indipendente dal trasporto, il titolo della firma, timestamp e nonce. Comodo per webhoop e controllo off-line.

Formati e tipi di token

JWT (JWS firmati)

Autosufficienti, controllati localmente; sono obbligatori «iss», «sub», «aud», «exp», «iat», «jti», «scope».
Rischio - La recensione è più complessa: usa TTL brevi (5-15 min) + elenco di «jti» richiamati per gli incidenti.

JWE (JWT cifrati)

Se il payload è sensibile (PII). Costi superiori alla complessità e spese generali.

Reference tokens

Identificatori opachi, convalidati tramite introspection da Authorization Server - più facile da richiamare/centralizzare.

PoP/DPoP

Agganciare un token a una chiave client o a una sessione TLS riduce il valore del token rubato.

Contenuto token minimo sufficiente

• «Iss», «sub», «aud», «exp», «iat», «nbf» (opzionale), «jti».
• scope '/' pertissions '(minimo necessario),' tenant '(per i multi-generici),' device _ compliant '/' amr '(metodo di autenticazione),' ip '/' asn '(se applicabile a un criterio).

• TTL brevi per access (5-15 min), refresh - 12-48 h (rotazione rotante).
• Il pubblico ('aud') è una risorsa molto specifica, altrimenti il token è riutilizzabile.
• Scoop - Azione e oggetto (ad esempio, 'payments: withdraw. read`).
• Dimensioni: 2-4 KB per intestazioni e proxy; Altrimenti potrebbero esserci problemi con i gateway.

Autorizzazioni e criteri

RBAC + ABAC: ruolo + contesto (organizzazione, geo, rischio, stato del dispositivo).
PEP/PDP - Verifica del token e decisione su API-gateway/proxy (Invoy/OPA) prima dell'applicazione.
Regole dichiarative: conservare in Git, passare in policy-test in 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 query (HMAC) e anti-replay

Quando si desidera: webhoop, integrazione senza OAuth, doppia verifica delle operazioni critiche.

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

• Rifiuta richieste temporali> © 300 secondi
• Noncè conserva 5-15 minuti e non riceve ripetizioni (cache replay).
• Firma la visualizzazione canonizzata della query (metodo, percorso, query, hash del corpo).

Idoneità e protezione transazionale

Idempotency-Key per le operazioni di prelievo/pagamento/creazione: la stessa chiave ha lo stesso effetto.
La durata della chiave è la durata del timeout aziendale (di solito 24-72 ore).
La logica sul lato server è di confrontare i parametri di query con quelli precedentemente fissati per questa chiave.

Browser e client mobili

PKCE è obbligatorio (client pubblici).
Refresh-token nel browser - evitare; se necessario - ROTATION + risposta alla ripetizione (dettaglio replay).
Storage di sessione> storage locale meglio: backend for frontend (BFF) è responsabile dei token.
SameSite, Secure, HttpOnly для cookie; KORS - allow-lists espliciti, intestazioni e metodi preferlight-cache sicuro.

m2m e integrazioni ad alto rischio

mTLS + OAuth2 Client Credentials con scorie e «aud».
IP/ASN allow-list sul gateway.
PoP/DPoP o firma HMAC sopra TLS per operazioni critiche.
Quote e rate limits per organizzazione/client/chiave.

Rotazioni, richiami e risposta agli incidenti

Rotazione dei segreti e delle chiavi di firma (JWKS) - Pianificato + forzato in caso di incidente.
Dual-key rollout: pubblica la nuova coppia chiave in anticipo (kid2), firma i token per lei, tieni la vecchia (kid1) per la convalida fino all'esaurimento della TTL.
Refresh-rotation: ogni scambio di refresh → un nuovo token, il vecchio diventa immediatamente nullo; La ripetizione è un segnale di compromissione.
Revocation: per JWT - elenchi «jti» ritirati per un breve periodo di tempo; per reference token - blocco immediato su AS.
Script break-glass: crediti statici temporanei con diritti minimi e TTL rigidi, fissati nel registro.

Rate limiting, bot-protezione e anti-sovrapprezzo

Limiti a tre livelli: per-key/per-IP/per-organizzazione.
Burst + sustained - token-serbatoio/finestra di scorrimento.
Controlli complessi: device fingerprint, segnali comportamentali, anomalie geo/ASN, CAPTCHA solo per UI.
Lockout/slowdown in caso di sovrapposizione della firma/NMAS e tentativi di autenticazione non completati.

Loging, metriche e SLO

Set minimo di loghi: 'sollest _ id', 'client _ id', 'sub', 'aud', 'scope', 'decision',' reason ',' jti ',' ip ',' asn ',' latency ',' quota'state '.

• Successo di validazione dei token (%), p95 tempo di verifica.
• Frequenza di deviazioni replay duplicate da Idempotency-Key.
• La percentuale di richieste di PoP/DPoP/mTLS.
• Errori «aud/scope» scaduti «exp», spostamenti di tempo (NTP).

• Disponibilità Auth/AS 99. 95 %/mes; p95 introspection ≤ 50 мс.
• Zero token con TTL <60 c in vendita (metrica di sicurezza).
• Meno di 0. 1% di errori al giorno (qualità delle integrazioni).

Esempi di configurazione

Avvoy - Verifica JWT e udienza

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;

Esempio di intestazione firma (webhoop)

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

Il server rifiuta se «t» è superiore a 300 c, «n» si è già incontrato o «s» non batte.

Protezione dei dati e privacy

Ridurre al minimo i marchi (in particolare il PII) e la durata della vita.
Cifrare i marchi sensibili (JWE) per le integrazioni di terze parti.
Mask/DLP nei fogli: non logifichi i corpi con PAN/PII, i token sono solo «kid »/flag, non è il segreto stesso.

Errori tipici

Token di accesso lungo e rifresh «eterni».
L'assenza di «aud »/« scope» è multifunzione.
Firma webhoop senza «timestamp »/« nonce».
Convalida JWT solo nell'applicazione e non nel gateway (PEP).
Nessuna rotazione e dual-key rollout.
I metodi CORS e i metodi non sicuri autorizzati non sono controllati dall'intestazione.
Deposito di token in localStorage senza BFF.

Road map di implementazione

1. Inventario API e classificazione (pubblico/partner/interni, sensibilità).
2. Seleziona il modello AuthN OAuth2/OIDC per quelli personalizzati, mTLS+Client Credentials/HMAC per m2m.
3. Token: TTL brevi, rigido'aud ', rigido', per operazioni critiche.
4. PEP sul gateway: convalida JWT, firma e rate limits prima dell'applicazione.
5. Anti-replay e idampotenza: timestamp/nonce/Idempotency-Key.
6. Rotazioni e JWKS: dual-key, automazione e alerting.
7. Osservabilità: metriche/SLO, registri di accesso, segnali UEBA.
8. Esercitazioni: scollegamento della chiave di firma, fuga di rifresh, sovraccarico delle quote.

Particolare per iGaming/Fintech

Pagamenti/pagamenti: solo mTLS + PoP/HMAC, scoop rigorosi ('withdraw. create '), idempotency è obbligatorio.
Partner (PSP/provider di contenuti): per-partner chiavi/certificati, IP/ASN allow-list, quote separate e dashboard.
GDPR/PCI DSS: riduzione dei marchi, proibizione del PII nei token di terze parti, logificazione dell'accesso alle risorse sensibili, access review regolari.
Anti-abuse: limiti comportamentali, geo-controllo, protezione contro il bonus abuse a livello API.

FAQ

JWT o reference token?
Prestazioni e autonomia JWT reference - recensione centralizzata e facilità di risposta incidente. Spesso ibrido - esterno - JWT, interno - reference.

C'è bisogno di JWE?
Solo se payload contiene PII/segreti. Altrimenti, JWS con i marchi minimi.

È possibile vivere su chiavi API?
Sì, ma solo con TTL brevi, quote rigorose, IP-allow-list e firma richieste. Per gli utenti - preferibilmente OAuth/OIDC.

È obbligatorio?
Non sempre. Ma per le transazioni high-risk (pagamenti, conclusioni) è estremamente desiderabile.

Totale

La sicurezza affidabile dell'API si basa su token a breve termine, scatti di precisione e pubblico, canali protetti (TLS/mTLS), firme di richieste e protezione rigorosa anti-replay, con limiti e osservabilità. Aggiungi rotazioni automatizzate, dual-key rollout e controllo politico sui gateway - e la tua API diventa resistente a fuoriuscite, ripetute e abusive, mantenendo al contempo prestazioni e gestibilità elevate.