API Key

Ein API Key ist wie ein Passwort, aber nicht für Menschen, sondern für Computer-Programme. Wenn du als Programmierer Wetterdaten von einem Dienst (wie OpenWeatherMap) abrufen willst, brauchst du ein Abo. Damit der Wetterdienst weiß, "Wer fragt da an?" und "Hat der bezahlt?", gibst du bei jeder Anfrage deinen API Key mit. Er ist eine lange, zufällige Zeichenkette: abcdef-123456-secret. Er identifiziert dein Projekt (nicht unbedingt den Endnutzer).

Merksatz: Ein eindeutiges Token (Zeichenfolge), das einem Client zugewiesen wird, um ihn bei API-Anfragen zu identifizieren und oft auch, um Nutzungsgrenzen (Rate Limits) und Abrechnung zu steuern.

Erstellung: Du gehst ins Developer-Dashboard deines Anbieters (z. B. OpenAI) und klickst "Create New Key".
Einbindung: Du speicherst den Key in einer Umgebungsvariable (.env Datei). OPENAI_API_KEY=sk-proj-1234...
Nutzung: Du sendest ihn im Header. Authorization: Bearer sk-proj-1234... oder x-api-key: ...

Warnung: Committe niemals .env Dateien oder API Keys in Git! Bots scannen GitHub in Sekunden und nutzen deinen Key, um Krypto zu minen (auf deine Kosten).

1. Scoping & Least Privilege

Ein "Root Key", der alles darf, ist gefährlich. Gute API-Systeme erlauben Scoped Keys. Du erstellst einen Key, der nur Schreibrechte für einen S3-Bucket hat. Wenn dieser Key gestohlen wird, ist der Schaden begrenzt ("Blast Radius" Minimierung). Im Frontend (Public) nutzt man "Publishable Keys", die gar nichts Kritisches dürfen (nur Daten senden, nicht lesen).

2. Key Rotation & Expiry

Keys sollten nicht ewig leben. Gute Praxis: Rotation.

Erstelle Key B.
Verteile Key B an alle Server.
Lösche Key A. Um Downtime zu vermeiden, müssen Apps Key-Updates dynamisch laden können (ohne Restart). Viele Compliance-Standards (SOC2) verlangen Rotation alle 90 Tage.

3. Rate Limiting & Quotas

Der API Key ist der primäre Identifikator für Rate Limiting. Der API Gateway (Kong, Nginx) führt eine Tabelle: "Key XYZ: 50 Req/Min". Bei 51 kommt 429 Too Many Requests. Das schützt die API vor Überlastung (DDoS) und "Noisy Neighbors".

1. MAC (Message Authentication Code) und HMAC

Wenn du einen einfachen API Key als Header mitsendest, ist er bei einer Man-in-the-Middle-Attacke (ohne TLS (Transport Layer Security)) sofort lesbar. Sicherere Systeme (wie AWS SigV4) verlangen, dass der Key nie das Netz betritt. Stattdessen signierst du den Inhalt deiner Anfrage kryptografisch verschlüsselt mit deinem Secret Key (HMAC). Du schickst den Body und diese mathematische Signatur (Hash) an den Server. Der Server hat das gleiche Secret, berechnet den Hash für den Body ebenfalls neu, und vergleicht beide Hashes. Das garantiert: "Die Anfrage kommt vom Key-Besitzer, und der Body wurde nicht manipuliert."

2. Hash-Funktionen in der Datenbank

Genau wie normale Passwörter, darf ein API-Anbieter die privaten Keys niemals im Klartext in der Datenbank abspeichern. Er nutzt One-Way-Hashfunktionen (Bcrypt/Argon2). Deshalb bekommst du bei Firebase oder Stripe deinen API Key nach dem Generieren immer nur ein einziges Mal angezeigt! Wenn du die Seite schließt, kann ihn nicht einmal mehr der Stripe-Support auslesen, da sie nur den unumkehrbaren Hash gespeichert haben. Verlierst du ihn, musst du das Key-Objekt überschreiben (rotieren).

3. Bearer Token vs API Key

Technisch gibt es einen feinen konzeptuellen Unterschied:

Ein API Key identifiziert meistens ein Projekt oder einen Bot. Er lebt oft unendlich lang und ist schwer zu widerrufen.
Ein Bearer Token (z.B. OAuth2 oder JWT) identifiziert einen echten Benutzer nach einem Login. Er hat extrem kurze Lebenszeiten (oft Minuten) und wird über spezielle Refresh-Tokens erneuert, was massiv sicherer für verletzliche Frontends (wie Browser-SPAs) ist.