Wie sicherst du eine REST-API ab (Authentifizierung, Autorisierung, Transport)?

Question

IT Interview Practice · Accepted Answer

Eine REST-API abzusichern bedeutet, bei jedem Request drei Fragen zu beantworten: **wer bist du** (Authentifizierung), **was darfst du tun** (Autorisierung) und **ist der Kanal privat** (Transport). Weil REST **stateless** ist, müssen Credentials mit jedem Request reisen, statt in einer Server-Session zu leben.

## Transport: immer HTTPS

Alles Folgende setzt **TLS/HTTPS** voraus. Ohne es reisen Tokens und API Keys im Klartext und können mitgeschnitten werden. Das ist nicht verhandelbar — ein Bearer Token über HTTP ist ein geleaktes Token.

## Authentifizierungs-Optionen

**API Keys** — ein statisches Secret in einem Header. Einfach; gut für Server-zu-Server und zum Identifizieren einer *Anwendung*, nicht eines Users. Allein schwach (kein Ablauf, kein Scope), außer man kombiniert mehr.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — der Standard für **delegierten** Zugriff ("lass App X meine Daten ohne mein Passwort lesen"). Die App erhält über einen Flow (z. B. Authorization Code) ein **Access Token** und sendet es als Bearer Token. So funktionieren "Sign in with Google" und Drittanbieter-Integrationen.

**JWT (JSON Web Token)** — ein verbreitetes *Format* für Tokens: ein signiertes, selbstenthaltenes Token, das Claims trägt (User-ID, Rollen, Ablauf). Der Server verifiziert die Signatur — kein Datenbank-Lookup nötig, was zu stateless REST passt.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Autorisierung: Scopes und Rollen

Authentifizierung beweist Identität; **Autorisierung** entscheidet über den Zugriff. Tokens tragen **Scopes** (`orders:read`, `orders:write`) oder Rollen; der Server prüft sie pro Endpoint und gibt `403 Forbidden` zurück, wenn sie unzureichend sind (vs. `401` für fehlende/ungültige Auth).

```text
No/invalid token         → 401 Unauthorized
Valid token, no scope    → 403 Forbidden
```

## Weitere Essentials

```text
✓ Short-lived access tokens + refresh tokens (limit blast radius if leaked)
✓ Rate limiting (429) to blunt brute-force and abuse
✓ Validate/sanitize all input; never trust the client
✓ Principle of least privilege on scopes
```

## Warum es wichtig ist

Sicherheit ist der Punkt, an dem ein kleiner Fehler zu einem Breach wird, daher nutzen Interviewer das, um zu sehen, ob du strukturell darüber nachdenkst statt Buzzwords aufzusagen. Das Signal, nach dem sie suchen, ist, dass du **die drei Schichten trennst** — Transport (HTTPS, immer), Authentifizierung (Identität beweisen, stateless, über Bearer Tokens/JWT/OAuth) und Autorisierung (Scopes und Least Privilege) — und dass du sie nicht vermischst, z. B. korrekt `401` für "nicht authentifiziert" versus `403` für "authentifiziert, aber nicht erlaubt" verwendest. Starke Antworten zeigen Bewusstsein für die praktischen Trade-offs: JWTs sind bequem und stateless, aber vor ihrem Ablauf schwer zu widerrufen (daher kurze Lebensdauern plus Refresh Tokens), API Keys identifizieren Apps, nicht User, und OAuth existiert genau dafür, dass User ihr Passwort nicht an Dritte geben. Es an die Statelessness von REST zu binden — Credentials bei jedem Request, keine Server-Session — zeigt, dass du verstehst, *warum* API-Sicherheit so aussieht, wie sie aussieht.

Transport: immer HTTPS

Authentifizierungs-Optionen

Autorisierung: Scopes und Rollen

Weitere Essentials

Warum es wichtig ist

Ähnliche Fragen