# API Security Deep Dive: AuthN, AuthZ und die Policy Enforcement Pipeline

TL;DR / Management Summary API Security in Microservices-Architekturen muss zentralisiert, zustandslos und hochperformant sein. Wir setzen auf OAuth 2.0 (für AuthN/Delegation) und OpenID Connect (OIDC, für Identität) in Verbindung mit JWTs. Die kritische Herausforderung liegt in der dezentralen Policy Enforcement und der effizienten Token-Validierung am API Gateway (Edge). Immer mTLS für Service-zu-Service-Kommunikation nutzen, um den inneren Perimeter zu schützen.

# 1. Einführung & Architektur

Moderne APIs sind das Lebenselixier digitaler Infrastrukturen. Historisch basierte Sicherheit oft auf statischen API Keys oder Basic Auth. Im Zeitalter von Microservices und Public APIs sind diese Methoden unzureichend, da sie keine feingranularen Berechtigungen (Scopes) unterstützen und ein hohes Risiko für Token-Diebstahl (Attacker hält Key, kann alles) darstellen.

# Warum brauchen wir das?

• Verteilte Komplexität: Jeder Microservice benötigt eine schnelle, verifizierbare Methode, um die Identität des Aufrufers festzustellen (AuthN) und zu prüfen, ob der Aufrufer die gewünschte Aktion durchführen darf (AuthZ).
• Zero-Trust-Prinzip: Es wird keinem Netzwerksegment mehr vertraut. Jede Anfrage, ob extern oder intern, muss explizit authentifiziert und autorisiert werden.
• Delegierte Identität: Wir müssen in der Lage sein, die Identität eines Endbenutzers (über OAuth 2.0) sicher an Backend-Services zu delegieren.

# Vergleich mit Alternativen

# Architektur-Diagramm (Token-Fluss)

Die Sicherheitspipeline gliedert sich primär in drei Stufen, wobei die Policy Enforcement Point (PEP) an der Edge die höchste Priorität hat.

graph TD
    A[Client/User] --> B{API Gateway / Load Balancer};
    subgraph Edge Enforcement (PEP)
        B --> C{1. JWT Validation (Signature, JTI, Clock Skew)};
        C --> D{2. Scope & Audience Check};
        D --> E{3. Rate Limiting / WAF};
    end
    E --> F[Auth Service / IdP]
    F --> G[Internal Service 1 (Resource Server)]
    G --> H[Internal Service 2 (mTLS)]

    style A fill:#f9f,stroke:#333
    style B fill:#ccf,stroke:#333
    style C fill:#aaf,stroke:#333
    style D fill:#aaf,stroke:#333
    style E fill:#aaf,stroke:#333
    style F fill:#afa,stroke:#333
    style G fill:#fcc,stroke:#333
    style H fill:#fcc,stroke:#333

    B -- Token Valid -- G;
    G -- mTLS / JWE -- H;

    F -- Public Keys (JWKS) --> B;

# Kernel-Sicht (Edge Enforcement)

In einem modernen Linux-basierten Stack (z.B. Service Mesh mit Envoy oder einem spezialisierten API Gateway) findet die JWT-Validierung in der Regel in einem dedizierten Layer statt, oft implementiert als C++ Module oder Go-Microservice (Sidecar).

Die Verarbeitung liegt oberhalb des Standard-Netzwerk-Stacks, wird aber oft durch hochperformante Libraries (z.B. OpenSSL für Kryptografie) im Kernel- oder User-Space beschleunigt. Der kritische Punkt ist hierbei die JWKS (JSON Web Key Set) Rotation: Das PEP muss die öffentlichen Schlüssel des IdP aktuell halten, um Signaturen effizient prüfen zu können, ohne bei jeder Anfrage das IdP befragen zu müssen (Introspection).

# 2. Installation & Grundkonfiguration (Praxis)

Wir konfigurieren einen resilienten Token-Validierungs-Stack basierend auf JWTs (OpenID Connect). Dies setzt voraus, dass ein zentraler Identity Provider (IdP, z.B. Keycloak, Okta) bereits steht.

# Voraussetzungen

• IdP: Konfiguriert, unterstützt RS256 oder PS256 (asymmetrische Signatur) und stellt ein öffentlich zugängliches /.well-known/openid-configuration sowie ein /jwks Endpoint bereit.
• Gateway: Ein Policy Enforcement Point (PEP), z.B. Kong, Envoy, oder eine Cloud-native Lösung (AWS API Gateway Custom Authorizer).
• Clock Synchronization: Absolut kritisch. Alle Services (IdP, Gateway, Backend-Services) müssen exakt synchronisiert sein (NTP/PTP), um Clock Skew zu verhindern, der zu unnötigen 401-Fehlern führt.

# Schritt-für-Schritt Setup (Der “Happy Path”)

Das Ziel ist es, das Gateway so zu konfigurieren, dass es Tokens zustandslos validiert und erst bei Bedarf (z.B. Revokation) den IdP befragt.

# 2.1 Konfiguration des IDP (Token-Payload)

Stelle sicher, dass der ausgestellte JWT die notwendigen Claims für die Autorisierung enthält:

1. iss (Issuer): Der Name des IdP. Das PEP muss prüfen, ob es den Token von der erwarteten Quelle erhält.
2. aud (Audience): Definiert, für wen der Token bestimmt ist (oft der Name des Resource Servers oder des Clients). Dies verhindert, dass ein Token, der für Service A bestimmt war, fälschlicherweise Service B aufruft. Dies ist eine der am häufigsten vergessenen Sicherheitsprüfungen!
3. exp (Expiration): Muss kurzlebig sein (5–15 Minuten).
4. scope (Scopes/Berechtigungen): Eine Liste der dem Benutzer gewährten Berechtigungen (z.B. read:user, write:data).

# 2.2 JWT-Validierung am PEP (Gateway)

Wir konfigurieren das Gateway, um die JWKS des IdP abzurufen und die Validierung lokal durchzuführen.

# 1. JWKS Endpunkt abrufen (Beispiel: IdP in $IDP_URL)
JWKS_URI=$(curl -s $IDP_URL/.well-known/openid-configuration | jq -r .jwks_uri)
echo "JWKS Endpoint: $JWKS_URI"

# 2. Key-Caching im Gateway definieren (Wichtig für Performance)
# Wir cachen die Keys für 1 Stunde, um den IdP-Traffic zu reduzieren,
# aber schnell auf Schlüssel-Rotation reagieren zu können.
GATEWAY_CONFIG_FILE="/etc/gateway/security.conf"

# Konfigurationssnippet (Gateway Pseudocode)
# Wichtig: Wir erzwingen eine Mindestgröße der Signatur (z.B. 2048 Bit)
echo "security.oauth.jwks_uri = $JWKS_URI" >> $GATEWAY_CONFIG_FILE
echo "security.oauth.key_cache_ttl_seconds = 3600" >> $GATEWAY_CONFIG_FILE
echo "security.oauth.required_audience = 'api-service-prod'" >> $GATEWAY_CONFIG_FILE
echo "security.oauth.required_algorithm = 'RS256'" >> $GATEWAY_CONFIG_FILE

# 3. Validation Pipeline aktivieren
# Der Gateway MUSS vor der Weiterleitung an den Service prüfen:
# - Signatur gültig (mit JWKS)
# - Token abgelaufen? (exp claim)
# - Issuer korrekt? (iss claim)
# - Audience korrekt? (aud claim)
# - JTI Replay Check (optional, aber empfohlen für kritische APIs)

systemctl restart api-gateway-pep

# 3. Deep Dive: Konfiguration für Profis

# Performance Tuning: JWT-Validierung

Die kryptografische Prüfung jeder Signatur ist teuer. Im Gegensatz zu Session-Cookies, wo oft nur ein Datenbank-Lookup nötig ist, muss bei JWTs echte asymmetrische Kryptografie angewandt werden.

1. Lokale Caching der Public Keys: Wie in Abschnitt 2 beschrieben. Vermeide bei jeder Anfrage den JWKS-Endpoint.
2. JWT Caching: Wenn möglich, sollten bereits validierte Tokens (vor allem die Claims-Payload) im Speicher des Gateways zwischengespeichert werden. Da Tokens kurzlebig sind (5-15 Min), ist der Cache-Invalidierungsaufwand gering.
3. Policy Decision Point (PDP) Offload: Halte die Autorisierungslogik schlank. Wenn die Berechtigung komplex ist (Role-Based Access Control, RBAC), sollte das PEP nur die notwendigen Claims extrahieren und an den Service weiterleiten. Die finale Entscheidung (Permit/Deny) trifft der Service selbst (oft mit einem Policy Decision Point wie Open Policy Agent (OPA) als Sidecar).

# Hardening & Security

# 3.1 Mutual TLS (mTLS) für Service-zu-Service-Kommunikation

Sobald der Verkehr das API Gateway passiert und in das interne Netzwerk gelangt, ist mTLS die absolute Pflicht. Ein kompromittierter Service könnte sonst ungehindert andere Services aufrufen, da das interne Netzwerk oft als “sicher” betrachtet wird.

• Implementierung: Nutze ein Service Mesh (z.B. Istio, Linkerd) oder ein dediziertes PKI-System (z.B. HashiCorp Vault) zur automatischen Zertifikatsrotation und -bereitstellung.
• Vorteil: mTLS authentifiziert beide Seiten der Verbindung (Service A beweist gegenüber Service B seine Identität und umgekehrt).

# 3.2 Token Lifespan Management

# 3.3 Schutz vor Replay Attacks (JTI)

Bei kritischen Transaktionen, auch wenn Access Tokens kurzlebig sind, können Angreifer einen gestohlenen Token mehrfach verwenden (Replay).

• Implementiere den JTI (JWT ID) Claim und speichere diesen im PEP-Cache (z.B. Redis) für die Dauer des exp. Wenn ein Token mit demselben JTI nochmals verwendet wird, wird die Anfrage abgelehnt.

# 3.4 Kryptografie-Standard-Auswahl

Niemals unsichere Algorithmen wie none (JWT ist ungesichert) oder HS256 für Public APIs verwenden, da dies das Geheimnis (Shared Secret) offengelegt. Wir nutzen asymmetrische Algorithmen (RS256, PS256), wobei PS256 (Probabilistic Signature Scheme) gegenüber RS256 als moderner und sicherer gilt.

# 4. Day-2 Operations: Wartung & Alltag

# Typische Tasks

# 4.1 Key Rotation (Zertifikate und JWKS)

Öffentliche Schlüssel des IdP müssen regelmäßig (z.B. alle 90 Tage) rotiert werden. Das PEP muss in der Lage sein, nahtlos von alten auf neue Schlüssel umzuschalten.

• Zero-Downtime-Strategie: Der IdP muss die alten Schlüssel für eine Übergangsfrist (z.B. 24 Stunden) weiter im /jwks Endpoint bereitstellen, damit Access Tokens, die mit dem alten Key signiert wurden, noch validiert werden können, bevor sie ablaufen.

# 4.2 Granulare Revokation

Ein Problem bei JWTs ist, dass sie zustandslos sind. Ein gestohlener Access Token ist gültig, bis er abläuft.

• Lösung: Bei einer erzwungenen Abmeldung oder einem Sicherheitsvorfall muss der betroffene Access Token sofort ungültig gemacht werden.
  1. Die jti des Tokens wird auf eine Revocation List (CRL) gesetzt, die vom PEP bei jeder Anfrage geprüft wird (oft in einem hochverfügbaren, schnellen Speicher wie Redis).
  2. Der zugehörige Refresh Token wird sofort beim IdP deaktiviert.

# Automatisierung (Ansible/Terraform)

Infrastructure-as-Code (IaC) muss die Sicherheitsrichtlinien und die Verbindung zum IdP idempotent verwalten.

# Ansible Beispiel: Konfiguration eines Kong API Gateway für OIDC/JWT Validation

- name: Configure JWT Plugin on Kong Gateway
  community.general.kong_plugin:
    kong_admin_uri: "http://kong-admin:8001"
    plugin: "jwt"
    service_id: "api-service-prod"
    config:
      claims_to_verify:
        - "exp"
        - "aud"
      maximum_expiration: 3600  # 1 hour max token lifetime
      issuer: "https://idp.mycompany.com/realms/prod"
      # Der JWKS Fetcher muss aktiviert und die URL bereitgestellt werden
      jwks_uri: "https://idp.mycompany.com/realms/prod/protocol/openid-connect/certs"
      key_claim_name: "kid" # Key ID im Header
  tags: [security, jwt-config]

# 5. Troubleshooting & “War Stories”

# Top 3 Fehlerbilder

# 1. Symptom A: HTTP 401 Unauthorized (Plötzlicher Anstieg, temporär)

• Fehlermeldung: “JWT signature verification failed” oder “Token expired (within leeway)”.
• Ursache: Clock Skew zwischen dem IdP (der iat setzt) und dem PEP (der exp prüft) oder dem Client. Ein Versatz von mehr als wenigen Sekunden führt zu sofortigen 401ern. Auch die fehlende Toleranz (leeway) im PEP ist oft schuld.
• Lösung: Überprüfe die NTP-Synchronisation auf allen beteiligten Systemen (timedatectl status). Konfiguriere im PEP eine leeway (Toleranzpuffer, z.B. 60 Sekunden), um minimale Abweichungen zu erlauben.

# 2. Symptom B: HTTP 403 Forbidden (AuthZ Fehler)

• Fehlermeldung: “Missing required scope” oder “RBAC policy mismatch”.
• Analyse: Der Token ist gültig (AuthN ok), aber die im Token enthaltenen Claims (scope, roles, permissions) reichen nicht aus, um die angeforderte Ressource aufzurufen.
• Lösung: Prüfe das Authorization Log des Resource Servers. Stimmen die im JWT erwarteten Claims mit den vom Client angeforderten überein? Oft muss das IdP neu konfiguriert werden, um die korrekten Claims in den Token zu mappen.

# 3. Symptom C: Hohe Latenz am Gateway

• Symptom: P99 Response Time des Gateways steigt signifikant bei Traffic-Spitzen.
• Ursache: Fehlende oder zu kurze Caching der JWKS. Das Gateway fragt ständig den IdP nach neuen Public Keys, was Roundtrips und Bandbreite kostet. Oder: Die Signaturprüfung wird in einem nicht-performanten Thread blockiert.
• Lösung: Erhöhe das JWKS-Caching-TTL (siehe Abschnitt 2.2). Prüfe die Threading-Modelle des PEP (sind kryptografische Operationen blockierend?).

# Recovery Szenarien

# Metadata Corruption (Verlorene IDP Secrets)

Wenn die privaten Schlüssel des IdP kompromittiert werden oder verloren gehen:

1. Sofortige Generierung eines neuen Schlüsselpaares (private/public key).
2. Publizierung des neuen öffentlichen Schlüssels im /jwks Endpoint.
3. Alle alten, signierten Access Tokens bleiben gültig, bis sie ablaufen (max. 5–15 Minuten).
4. Alle Clients müssen neue Tokens über den Refresh-Flow anfordern.

# Anekdote: Das vergessene “aud” (Audience)

Wir hatten den Fall, dass ein interner Service (Service A) einen Token anforderte, der nicht explizit die aud des zweiten Services (Service B) enthielt. Service B war lax konfiguriert und prüfte die aud-Claim nicht. Dies führte dazu, dass interne Entwickler versehentlich oder absichtlich Daten in einem anderen Service lesen konnten, für den sie keine Berechtigung hatten. Lektion: Immer die aud (Audience) Claim in jedem PEP strikt validieren!

# 6. Monitoring & Alerting

Die Sicherheitsinfrastruktur muss als Black Box betrachtet und aktiv überwacht werden.

# Metriken (KPIs)

# Alerting-Regeln

• PAGER (Kritisch):

  • Alert 1: High 401 Spike: Wenn die pep_401_error_rate_total um mehr als 500% der Baseline in den letzten 5 Minuten steigt. (Deutet auf IdP-Ausfall, fehlerhafte Key-Rotation oder massiven Replay/DDoS-Angriff hin).
  • Alert 2: IdP Key Mismatch: pep_token_validation_failure_algorithm_mismatch > 0. (Deutet auf fehlerhafte JWKS-Publizierung hin).

• TICKET (Wichtig):

  • Alert 3: Low Token Lifespan: Wenn der Durchschnitt des exp Claims der aktuell validierten Tokens nahe an 5 Minuten kommt (proaktive Warnung, wenn Tokens zu kurzlebig werden und Clients Probleme bekommen könnten).

# Tools

• Prometheus Exporter: Ein Custom Exporter im PEP, der die Latenz und die Fehlercodes der Token-Validierung in den Tags auth_status: success/401/403 misst.
• Logging: Alle 401/403 Events müssen in einem zentralen SIEM/Log-Aggregator (ELK, Splunk) gesammelt werden, um Angriffsversuche analysieren zu können.

# 7. Fazit & Empfehlung

API Security ist ein kontinuierlicher Prozess, der weit über die einfache Nutzung von OAuth 2.0 hinausgeht. Der kritische Engpass ist das Policy Enforcement Point (PEP) am Gateway, das effizient, asynchron und vollständig gehärtet sein muss.

Wann würde ich es nicht einsetzen? Token-basierte Sicherheit ist Overkill für extrem einfache, monolithische Anwendungen mit geringer Benutzerzahl. Hier können Session-Cookies mit Datenbank-Lookup unter Umständen einfacher zu managen sein, wenn keine Delegation erforderlich ist. Für alles, was Microservices, Cloud-native oder mobil ist: OAuth/OIDC ist Pflicht.

Ausblick: Die Zukunft liegt in noch feingranulareren Autorisierungsmodellen wie ABAC (Attribute-Based Access Control), oft implementiert über Sidecars (OPA) und Policy-Sprachen wie Rego. Service Meshes werden die mTLS-Implementierung und die Policy Enforcement Point (PEP)-Funktionalität immer tiefer in die Infrastruktur integrieren.

# Anhang: Cheatsheet (API Security Validierungs-Flow)

# Referenzen

• IETF RFC 6749 (OAuth 2.0 Authorization Framework)
• OpenID Connect Core 1.0
• CISA API Security Guidance (US Gov)
• OWASP API Security Top 10