API Authentication

Die gängigsten Methoden im HTTP-Header:

1. Basic Auth: Der Klassiker (aber veraltet). Authorization: Basic dXNlcjpwYXNz (Base64 von user:pass). Problem: Man schickt das Passwort bei jedem Request mit. Wenn HTTPS versagt, ist das Passwort weg.
2. API Key: Ein langer geheimer String. X-API-Key: abcdef123456. Gut für Server-zu-Server. Schlecht für Mobile Apps (kann extrahiert werden).
3. Bearer Token: Der moderne Standard. Authorization: Bearer <token>. Das Token (oft ein JWT) ist ein temporäres Ticket. Wenn es geklaut wird, läuft es bald ab.

1. OAuth 2.0 & OpenID Connect (OIDC)

Für komplexe Szenarien ("Log in with Google") reicht ein einfacher Key nicht. Hier nutzt man OAuth2. Es gibt verschiedene "Flows" (Abläufe):

• Client Credentials Flow: Maschine redet mit Maschine (Backend zu Backend). Gibt API Key, kriegt Token.
• Authorization Code Flow: User klickt "Allow", Browser wird umgeleitet, Server tauscht Code gegen Token. Das entkoppelt die Credentials vom Zugriff. Die App sieht nie das Passwort des Users.

2. mTLS (Mutual TLS)

Die sicherste Methode (Banken, Zero Trust). Normalerweise authentifiziert sich nur der Server per Zertifikat ("Ich bin google.com"). Bei mTLS authentifiziert sich auch der Client mit einem Zertifikat ("Ich bin Partner-Server A"). Der TLS-Handshake gelingt nur, wenn beide Seiten gültige Zertifikate haben. Auth passiert also auf Layer 4/5 (Transport), bevor überhaupt der erste HTTP-Byte gesendet wird.

3. HMAC Signatures (Alternative zu Tokens)

AWS S3 nutzt das. Man schickt keinen Key über die Leitung. Man signiert den Request. Unterschrift = Hash(Request + SecretKey). Der Server hat auch den SecretKey und rechnet nach. Vorteil: Wenn der Request unterwegs verändert wird (Man-in-the-Middle), stimmt die Unterschrift nicht mehr. Und man schickt das Secret nie über das Netz.

Der OAuth 2.0 PKCE Flow (Proof Key for Code Exchange)

Früher nutzte man für Mobile-Apps den "Implicit Flow" (Token wird direkt in der URL zurückgegeben). Dieser gilt heute als unsicher! Der empfohlene Standard ist "Authorization Code Flow with PKCE". Ablauf:

1. Die App generiert einen zufälligen code_verifier und errechnet den Hash (code_challenge).
2. Die App öffnet den Browser für den Login und schickt die code_challenge mit.
3. Der Server merkt sich die Challenge und gibt einen Auth-Code zurück.
4. Die App tauscht den Code gegen ein Token und sendet dabei den originalen code_verifier mit. Der Server rechnet nach, ob Verifier = Challenge. Da ein bösartiger Interceptor nur den Code (Schritt 3) klauen kann, aber nicht den intern generierten Verifier (Schritt 1), scheitert der Diebstahl.

Token Manipulation & Key Rollover

Wenn ein JWT mit einem Public/Private Key Pair signiert wird (RS256), hast du ein Problem: Was passiert, wenn der Private Key kompromittiert ist? Enterprise APIs nutzen JWKS (JSON Web Key Sets). Unter dem Endpoint /.well-known/jwks.json veröffentlicht der Auth-Server seine Public Keys, und jeder Key hat eine "kid" (Key ID). Im Header deines JWTs steht z. B. {"alg": "RS256", "kid": "key-2026-v1"}. So kann der Auth-Server fließend unbemerkt neue Keys einführen ("Key Rollover"), während alte Token langsam ablaufen.

API Gateways & Edge Authentication

In einer Microservice-Architektur implementiert nicht jeder Service (User, Orders, Payments) seine eigene Auth-Logik. Das ist ein massives Sicherheitsrisiko. Man lagert Auth an den "Edge" (den Rand des Netzwerks) aus, meist in ein API Gateway (Kong, AWS API Gateway) oder in einen Ingress Controller/Sidecar (Istio). Das Gateway macht den teuren Krypto-Check des Tokens, validiert die Ablauffrist und extrahiert die User-Infos. Es leitet den Request dann an das interne Backend weiter, z.B. versehen mit speziellen, schnellen internen Headern (X-User-Id), die im sicheren internen Netz bedingungslos vertraut werden.