API-Sicherheit und Token

Kurze Zusammenfassung

API-Sicherheit ist eine Kombination aus Authentifizierungs-, Autorisierungs-, kryptografischen Schutz-, Anti-Missbrauchs- und Beobachtbarkeitsmechanismen, die sicherstellt, dass die Anforderung das erwartete Subjekt zu der erwarteten Ressource im erwarteten Kontext ausführt. Das Schlüsselartefakt ist ein Token (oder die Signatur der Anforderung), das die Berechtigung zum Aufruf beweist. Eine gute Architektur stützt sich auf kurzlebige Token, klare Skopes, minimale Privilegien, Wiederholungsschutz, Ratenlimiting und Betriebsverfahren (Rotationen, Audits, Vorfälle).

API-Authentifizierungsmodelle: Wann und was zu wählen ist

API-Schlüssel (statisches Geheimnis)

Einfach für B2B-Integrationen und risikoarme Szenarien. Trägt keinen Kontext, erfordert die Speicherung auf der Seite des Dienstes.
Nur mit IP/ASN-Allow-List, festen Quoten, Short TTL und Rotationen verwenden.

OAuth 2. 1 / OIDC

Standard für Benutzer- und Partnerintegrationen: access token (kurz lebend) + refresh token (Rotation) + scopes.
Öffentliche Kunden - mit PKCE; vertrauliche Clients - mit Client Secret/mTLS.

Client Credentials (m2m)

Mashina→mashina: Zugriffstoken für Dienste nach streng spezifizierten Scopes und Audience, oft ohne Refresh.

mTLS (gegenseitiges TLS)

Bindet Identität an einen Kanal. Ideal für Hochrisiko- oder Zahlungsintegrationen (PoP über TLS).
Kann mit OAuth kombiniert werden (Token nur für mTLS-Clients).

Anforderungsunterschriften (HMAC/EdDSA)

Wenn Sie einen transportunabhängigen PoP benötigen: Signaturtitel, Timestamp und Nonce. Praktisch für Webhooks und Offline-Validierung.

Token-Formate und -Typen

JWT (JWS, signiert)

Autark, lokal geprüft; obligatorisch sind "iss", "sub", "aud'," exp "," iat "," jti "," scope ".
Risiko - Rückruf ist komplizierter: Verwenden Sie kurze TTLs (5-15 min) + Liste der zurückgezogenen „jti“ bei Vorfällen.

JWE (JWT-verschlüsselt)

Erforderlich, wenn payload empfindlich ist (PII). Kosten - höhere Komplexität und Overhead.

Reference tokens

Undurchsichtige IDs, verifiziert über Introspection im Authorization Server - einfacher Rückruf/Zentralisierung.

PoP/DPoP

Die Bindung des Tokens an den Schlüssel des Kunden oder an die TLS-Sitzung verringert den Wert des gestohlenen Tokens.

Inhalt des Tokens: minimal ausreichend

Empfohlene Stempel (JWT):

"iss" (issuer), "sub" (subject), "aud' (target system/resource)," exp "(term)," iat "," nbf "(optional)," jti ".
„scope “/„ permissions“ (Mindestanforderungen), „tenant“ (für Multitenant), „device _ compliant “/„ amr“ (Authentifizierungsmethode), „ip “/„ asn“ (falls auf die Richtlinie anwendbar).

Regeln:

Kurze TTL für Zugang (5-15 min), refresh - 12-48 Stunden (mit rotierender Rotation).
Das Publikum ('aud') ist eine streng spezifische Ressource, ansonsten ist der Token „wiederverwendbar“.
Scopes - Aktion und Objekt (z.B. 'payments: withdraw. read`).
Größe - ≤ 2-4 KB für Header und Proxies; sonst sind Probleme mit den Gatewees möglich.

Autorisierung und Richtlinien

RBAC + ABAC: Rolle + Kontext (Organisation, Geo, Risiko, Gerätestatus).
PEP/PDP: Verifizierung des Tokens und Entscheidung am API-Gateway/Proxy (Envoy/OPA) vor der Anwendung.
Deklarative Regeln: in Git speichern, Policy-Tests im CI durchführen.

Rego Beispiel (vereinfacht):

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
}

Anforderungssignatur (HMAC) und Anti-Replay

Bei Bedarf: Webhooks, Integrationen ohne OAuth, doppelte Überprüfung kritischer Operationen.

Überschriftenschema (Beispiel):


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

Regeln:

Anfragen mit Zeitabstand> ± 300 s ablehnen.
Speichern Sie Nonce 5-15 Minuten und akzeptieren Sie keine Wiederholungen (Replay-Cache).
Signieren Sie die kanonisierte Ansicht der Abfrage (Methode, Pfad, Abfrage, Body-Hash).

Idempotenz und Transaktionsschutz

Idempotency-Key für Abbuchungs-/Auszahlungs-/Erstellungsvorgänge: Gleicher Schlüssel → gleiche Wirkung.
Die Lebensdauer des Schlüssels beträgt die ≥ Geschäftszeit (normalerweise 24-72 Stunden).
Serverseitige Logik: Vergleichen Sie die Anforderungsparameter mit den zuvor für diesen Schlüssel festgelegten.

Browser- und mobile Clients

PKCE ist obligatorisch (Public-Clients).
Refresh-Token im Browser - vermeiden; bei Bedarf - ROTATION + Replay-Response (Replay-Detect).
Speicher: Sitzungsspeicher> lokaler Speicher; besser - Backend for Frontend (BFF) ist für Token verantwortlich.
SameSite, Secure, HttpOnly для cookie; CORS - explizite Allow-Listen, Header und Methoden; preflight-caching ist sicher.

m2m und Hochrisiko-Integrationen

mTLS + OAuth2 Client Credentials mit Scopes und "aud'.
IP/ASN allow-list auf dem Gateway.
PoP/DPoP oder HMAC-Signatur über TLS für kritische Operationen.
Kontingente und Rate Limits pro Organisation/Kunde/Schlüssel.

Rotationen, Rückrufe und Reaktionen auf Vorfälle

Rotation von Geheimnissen und Signaturschlüsseln (JWKS): nach Zeitplan + bei einem Vorfall erzwingen.
Dual-Key-Rollout: Veröffentlichen Sie ein neues Schlüsselpaar im Voraus (kid2), unterschreiben Sie die Token, halten Sie das alte (kid1) zur Validierung, bis die TTL erschöpft ist.
Refresh-Rotation: Jeder Austausch von Refresh → ein neues Token, das alte wird sofort ungültig; Wiederholung ist ein Kompromittierungssignal.
Revocation: für JWT - Listen der kurzfristig zurückgezogenen „jti“; für Referenz-Token - sofortige Sperrung auf AS.
Break-Glass-Szenarien: temporäre statische Credits mit minimalen Rechten und harter TTL, protokollieren.

Ratenbegrenzung, Bot-Schutz und Brute-Force-Schutz

Dreischichtige Grenzen: per-key/per-IP/per-Organisation.
Burst + nachhaltig: Token-Tank/Schiebefenster.
Komplexe Prüfungen: Device Fingerprint, Verhaltenssignale, Geo/ASN Anomalien, CAPTCHA nur für UI.
Lockout/Slowdown bei Signaturüberschreitung/NMAS und fehlgeschlagenen Authentifizierungsversuchen.

Protokollierung, Metriken und SLOs

Mindestprotokolle: 'request _ id', 'client _ id', 'sub', 'aud',' scope', 'decision', 'reason', 'jti', 'ip', 'asn', 'latency', 'quota _ state'.

Metriken:

Token-Validierungserfolg (%), p95 Verifizierungszeit.
Häufigkeit von Replay-Abweichungen, Idempotency-Key Duplikate.
Anteil der Anfragen mit PoP/DPoP/mTLS.
Fehler 'aud/scope', abgelaufene' exp', Zeitverschiebungen (NTP).

SLO (Beispiele):

Verfügbarkeit Auth/AS ≥ 99. 95 %/Monat; p95 introspection ≤ 50 мс.
Null Token mit TTL <60 c im Prod (Sicherheitsmetrik).
Weniger als 0. 1% Fehler 'aud/scope' pro Tag (Qualität der Integrationen).

Konfigurationsbeispiele

Envoy: JWT und Publikumsprüfung

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;

Beispiel für einen Signaturtitel (Webhooks)


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

Der Server lehnt ab, wenn't 'älter als 300 c ist,' n 'bereits getroffen hat oder' s' nicht schlägt.

Datenschutz und Privatsphäre

Minimieren Sie Stempel (insbesondere PII) und Lebensdauer.
Verschlüsseln Sie sensible Stempel (JWE) für Drittintegrationen.
Maske/DLP in den Protokollen: Keine Körper mit PAN/PII protokollieren, Token sind nur 'kid'/Flags, nicht das Geheimnis selbst.

Typische Fehler

Langlebige Access-Token und „ewige“ Refresh.
Das fehlen von 'aud'/' scope' → Mehrzweck-Token.
Signatur von Webhooks ohne' timestamp '/' nonce'.
JWT-Check nur in der App, nicht auf der Gateboy (PEP).
Keine Rotation und Dual-Key-Rollout.
CORS „“ und erlaubte unsichere Methoden ohne Header-Kontrolle.
Speicherung von Token in 'localStorage' ohne BFF.

Roadmap für die Implementierung

1. API-Inventar und Klassifizierung (öffentlich/Partner/intern, Sensitivität).
2. AuthN-Modellauswahl: OAuth2/OIDC für benutzerdefinierte, mTLS + Client Credentials/HMAC für m2m.
3. Token: kurze TTL, strenge' aud', Scopes, DPoP/PoP für kritische Operationen.
4. PEP auf dem Gateway: Validierung von JWT, Signaturen und Rate Limits vor der Anwendung.
5. Anti-Replay und Idempotency: timestamp/nonce/Idempotency-Key.
6. Rotationen und JWKS: Dual-Key, Automatisierung und Alerting.
7. Beobachtbarkeit: Metriken/SLOs, Zugriffsprotokolle, UEBA-Signale.
8. Das Lernen: otosw des Schlüssels der Unterschrift, das Ausfließen refresh, die Überlastung der Quoten.

Spezifität für iGaming/Fintech

Zahlungen/Auszahlungen: nur mTLS + PoP/HMAC, strikte Scopes ('withdraw. create'), idempotency erforderlich.
Partner (PSPs/Content Provider): Per-Partner-Schlüssel/Zertifikate, IP/ASN-Allow-Liste, individuelle Kontingente und Dashboards.
DSGVO/PCI DSS: Minimierung von Stigmen, Verbot von PII in Drittanbieter-Token, Protokollierung des Zugriffs auf sensible Ressourcen, regelmäßige Zugriffsprüfung.
Anti-Missbrauch: Verhaltensgrenzen, Geo-Kontrolle, Schutz vor Bonus-Missbrauch auf API-Ebene.

FAQ

JWT oder Referenzmarke?
JWT - Leistung und Autonomie; reference - zentrale Rückrufaktion und Einfachheit der Incident-Response. Oft Hybrid: extern - JWT, intern - Referenz.

Brauchen Sie JWE?
Nur wenn payload PII/Geheimnisse enthält. Ansonsten - JWS mit minimalen Stempeln.

Kann ich von API-Schlüsseln leben?
Ja, aber nur mit kurzer TTL, strengen Kontingenten, IP-allow-list und Signatur der Anfragen. Für Benutzer - vorzugsweise OAuth/OIDC.

Ist DPoP/PoP obligatorisch?
Nicht immer. Aber für High-Risk-Transaktionen (Zahlungen, Schlussfolgerungen) - äußerst wünschenswert.

Summe

Robuste API-Sicherheit basiert auf kurzlebigen Token, präzisen Scopes und Zielgruppen, sicheren Kanälen (TLS/mTLS), Anforderungssignaturen und strengem Anti-Replay-Schutz, der durch Limits und Beobachtbarkeit verstärkt wird. Fügen Sie automatisierte Rotationen, Dual-Key-Rollout und politische Kontrolle auf Gatetways hinzu - und Ihre API wird widerstandsfähig gegen Lecks, Wiederholungen und Missbrauch, während Sie eine hohe Leistung und Verwaltbarkeit beibehalten.