Authentifizierung in APIs: API-Key, Basic Auth

In den bisherigen Lektionen haben wir gelernt, wie eine REST-API aufgebaut wird – mit HTTP-Methoden, sauberen URL-Strukturen und Headern. Eine offene API wäre aber ein Sicherheitsalbtraum – jede*r könnte deine Daten lesen oder ändern. Es braucht einen Türsteher: Authentifizierung (wer bist du?) und Autorisierung (was darfst du?).

Diese Lektion ist der Einstieg ins Sicherheits-Thema. Du lernst die zwei einfachsten Verfahren – API-Keys und Basic Authentication – mit allen Vor- und Nachteilen. In L5 kommt dann JWT, in L6 das moderne OAuth2/OIDC. Wer diese Basis hier sicher beherrscht, hat einen leichteren Einstieg in die Folgelektionen.

1) Authentifizierung vs. Autorisierung – die zwei A's

Zwei Begriffe, die ständig verwechselt werden, aber etwas grundlegend Verschiedenes bedeuten. Eine Analogie hilft: stell dir einen Eingangsbereich vor. Beim Pförtner zeigst du deinen Ausweis – das ist Authentifizierung, der Pförtner stellt fest, dass du wirklich „Anna Müller" bist. Dann schaut er in eine Liste: darf Anna in Raum 305? Das ist Autorisierung, die Prüfung der Berechtigung.

2) Die drei Klassiker im Überblick

Es gibt einen ganzen Werkzeugkasten an Auth-Verfahren für APIs. Die drei wichtigsten, mit denen du täglich umgehst:

3) API-Key: der einfachste Türsteher

Ein API-Key ist im Grunde ein langer Zufalls-String, den der Anbieter einer API generiert und seinen Kunden gibt. Wer den Key hat, darf rein. Wer keinen hat, fliegt raus. Wie ein Eintritts-Wristband im Schwimmbad: niemand prüft deinen Ausweis, nur das Wristband zählt.

Im Request wird der Key meist als Header mitgesendet (manchmal auch als Query-Parameter, was aber weniger sicher ist, weil URLs in Logs landen):

GET /api/products HTTP/1.1
Host: api.example.com
X-API-Key: 7f3a9b2c-4d8e-1f0a-c5b7-2e9d6a8b1c4f

Server-Logik: der Key wird in einer Tabelle nachgeschlagen, dort sind Account, Berechtigungen, eventuelle Rate-Limits hinterlegt. Wenn der Key gültig ist, geht der Request durch. Sonst 401 Unauthorized.

Typische Einsatzbereiche: Service-zu-Service-Integration (dein Backend ruft eine Wetter-API auf), Test-/Sandbox-APIs, Stripe-API für Zahlungen, Mailchimp, Twilio. Überall, wo nicht ein einzelner Mensch, sondern ein technisches System der Konsument ist.

Wichtig: ein API-Key sagt nichts über die Person. Wenn drei Mitarbeiter den gleichen Key benutzen, weiß der Server nicht, wer gerade anfragt – nur „jemand mit diesem Key war's". Für Endnutzer-Apps ist das selten passend.

4) Basic Authentication: der Klassiker aus den 90ern

Basic Auth ist im HTTP-Standard von Anfang an enthalten. Der Client sendet Username und Passwort mit jedem Request mit, in einem speziellen Format: username:password wird Base64-kodiert und im Authorization-Header gesendet:

Vorteil von Basic Auth: HTTP-Standard, von jedem Browser nativ unterstützt. Wenn der Server mit 401 und Header WWW-Authenticate: Basic antwortet, zeigt der Browser automatisch ein Login-Popup an.

Nachteile: das Passwort wandert mit jedem Request mit (kein Logout möglich, kein Ablaufdatum), bei Leak ist alles weg, kein Refresh-Mechanismus. Heute hauptsächlich noch für interne Admin-Endpunkte, simple Skript-Aufrufe und im Linux-Ökosystem (curl, wget) anzutreffen.

5) API-Key vs. Basic Auth: Entscheidungshilfe

Beide Verfahren sind „simpel". Wann nimmt man was?

6) Der Auth-Flow im Bild

Damit du die Mechanik mental vor Augen hast, hier der typische Ablauf eines geschützten API-Aufrufs als Sequenzdiagramm:

7) Sicherheits-Mindeststandards

Egal welches Verfahren – diese Regeln sind nicht verhandelbar. Wer sie ignoriert, baut Sicherheitslücken ein, die in Penetration-Tests sofort auffallen:

8) Beispiel-Implementierung: Server-Logik

Wie sieht das im Code aus? Hier eine vereinfachte Middleware in Python (Flask), die einen API-Key prüft:

from functools import wraps
from flask import request, jsonify

def require_api_key(f):
    @wraps(f)
    def wrapper(*args, **kwargs):
        key = request.headers.get('X-API-Key')
        if not key:
            return jsonify(error='MISSING_KEY'), 401
        account = db.lookup_account_by_key(key)
        if not account or not account.active:
            return jsonify(error='INVALID_KEY'), 401
        request.account = account   # für Folgecode verfügbar
        return f(*args, **kwargs)
    return wrapper

@app.route('/api/products')
@require_api_key
def list_products():
    return jsonify(db.products_for(request.account))

Diese Logik ist absichtlich kurz – in der Realität kommen noch Aspekte dazu: Rate-Limits, Audit-Logs, Berechtigungs-Checks pro Endpunkt (das ist Autorisierung), Caching der Key-Lookups (Performance). Aber das Grundprinzip ist genau das: vor jedem geschützten Endpunkt prüft eine Middleware den Header.

9) Wie kommt man als Konsument an einen Key?

Aus Sicht eines API-Konsumenten (also: du willst eine fremde API nutzen):

1. Account anlegen beim Anbieter (z.B. Stripe, OpenAI, Mailchimp).
2. API-Key generieren im Developer-Dashboard. Meist als langer Zufalls-String wie sk_live_4eC39HqLyjWDarjtT1zdp7dc....
3. Sicher speichern: nicht im Code, nicht im Git, sondern in einer .env-Datei oder einem Secret-Manager.
4. In Anfragen verwenden: X-API-Key: ... oder Authorization: Bearer ... (je nach Anbieter).
5. Rotieren, wenn der Key verdächtigt wird kompromittiert zu sein. Neuen anlegen, alten löschen.

Bewusst gewählte Konventionen vieler Anbieter: ein Prefix wie sk_ (Stripe Secret Key), pk_ (Public Key), test_ oder live_ macht sofort klar, was für ein Key das ist. So erkennt man auch in Logs schnell, dass „da hat jemand seinen Stripe-Test-Key geleakt".

10) Häufige Klausurfragen und Stolperfallen

Diese Punkte werden in IHK-Klausuren gerne abgefragt:

• Authentifizierung vs. Autorisierung – Begriffe definieren und Beispiele zuordnen.
• Statuscodes 401 vs. 403 – Unterschied erklären und Situationen zuordnen.
• Basic Auth: ist Base64 verschlüsselt? Antwort: Nein, das ist nur Kodierung. Sicherheit kommt aus HTTPS.
• Welche Auth-Methode wofür? – API-Key für Service-zu-Service, Basic Auth für simple interne Tools, Token-Verfahren für moderne Apps.
• Sicherheits-Hygiene: warum nie Keys im Frontend, nie im Git, nie in URLs.

Zusammenfassung

Authentifizierung (AuthN) = „wer bist du?" – fehlt sie → 401. Autorisierung (AuthZ) = „was darfst du?" – fehlt sie → 403. Verwirrend: HTTP-Header heißt Authorization, ist aber für AuthN. API-Key: ein langer geheimer String, im Header X-API-Key. Einfach, gut für Service-zu-Service, keine User-Identität. Basic Authentication: Authorization: Basic <base64(user:pass)> – Base64 ist KEINE Verschlüsselung, nur Kodierung. Sicherheit kommt aus HTTPS. Token-basierte Verfahren (JWT, Bearer) sind heute Standard – Vertiefung in L5 und L6. Hygiene-Regeln: HTTPS Pflicht, Passwörter in DB nur gehasht (bcrypt/Argon2 – siehe K11), Keys rotierbar, Rate Limits. Anti-Patterns: Keys im Frontend hardcoden, in URLs, im Git. Auswahl-Faustregel: Service-zu-Service → API-Key. Internes Tool → Basic Auth + HTTPS. Endnutzer-App → Token. Klausur-Stolperfallen: 401 vs. 403, Base64 ≠ Verschlüsselung, korrekte Methodenwahl. Nächste Lektion: JWT.