Authentifizierung und Autorisierung

Authentifizierung beantwortet die Frage "Wer bist du?". Ein Client weist seine Identität gegenüber dem Server nach, etwa mit Zugangsdaten oder einem Token. Autorisierung beantwortet die Frage "Was darfst du?". Sie entscheidet, ob die nachgewiesene Identität auf eine bestimmte Ressource zugreifen oder eine Aktion ausführen darf. Beides ist getrennt: Man kann korrekt authentifiziert sein und trotzdem keine Berechtigung haben.

HTTP definiert dafür ein allgemeines Framework (RFC 7235). Der typische Ablauf: Der Server antwortet auf eine Anfrage ohne Zugangsdaten mit 401 Unauthorized und einem WWW-Authenticate-Header, der das erwartete Verfahren nennt. Der Client wiederholt die Anfrage dann mit den Zugangsdaten im Authorization-Header.

Wichtige Statuscodes laut MDN:

• 401 Unauthorized: nicht (gültig) authentifiziert; der Client darf es erneut versuchen.
• 403 Forbidden: gültig authentifiziert, aber nicht berechtigt; ein erneuter Versuch ist zwecklos.
• 407 mit Proxy-Authenticate und Proxy-Authorization: dasselbe Prinzip für Proxys.

Gängige Mechanismen im Überblick:

• API-Keys: ein statischer Schlüssel pro Client, oft in einem Header. Einfach, aber meist nur grobe Identifikation.
• HTTP Basic: Benutzername und Passwort werden im Authorization-Header übertragen. Die Daten sind nur kodiert (Base64), nicht verschlüsselt, daher zwingend nur über HTTPS/TLS verwenden.
• Bearer-Token / JWT: ein Inhaber-Token wird mit dem Schema Bearer gesendet (RFC 6750). JWT (RFC 7519) ist ein verbreitetes, in sich strukturiertes Tokenformat.
• OAuth 2.0 (RFC 6749): Industriestandard für Autorisierung per Delegation. Eine Anwendung erhält vom Nutzer über definierte Flows (z. B. Authorization Code mit PKCE, Client Credentials) ein Access-Token, ohne dessen Passwort zu kennen. OAuth 2.0 regelt also Zugriffsrechte, nicht primär die Identitätsprüfung des Endnutzers.
• Sessions / Cookies: Nach einem Login speichert der Server eine Sitzung und der Browser sendet die Session-ID per Cookie automatisch mit; typisch für klassische Webanwendungen.

Die Header-Zeile sitzt immer im Request und folgt dem Muster Authorization: , also etwa Authorization: Basic ... oder Authorization: Bearer .... Browser nutzen für Basic-Zugangsdaten UTF-8-Kodierung. Beachten Sie: Der Authorization-Header wird bei Cross-Origin-Redirects entfernt.

Hinweis zur Praxis: Die folgenschwersten API-Lücken liegen weniger bei der Authentifizierung als bei der Autorisierung. Wer authentifiziert ist, darf nicht automatisch alles. Fehlende oder fehlerhafte Berechtigungsprüfungen pro Objekt und pro Aktion führen dazu, dass Nutzer fremde Daten lesen oder ändern können. Prüfen Sie Berechtigungen daher serverseitig bei jedem Zugriff.

GET /api/orders/42 HTTP/1.1
Host: api.example.com

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api"

GET /api/orders/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1Ni...

HTTP/1.1 403 Forbidden

Ablauf: erst 401 (nicht authentifiziert), dann Anfrage mit Bearer-Token; 403 zeigt fehlende Berechtigung trotz gültiger Identität.

Best Practices für API-Authentifizierung

Authentifizierungs-Endpunkte sind laut OWASP API Security Top 10 (API2:2023 Broken Authentication) ein leichtes Ziel, weil sie für jeden erreichbar sind. Wer sie kompromittiert, übernimmt fremde Konten. Die folgenden Praktiken fassen die belegten Empfehlungen von OWASP und oauth.net zusammen.

Transport und Token-Handhabung

• Anmeldedaten und Passwörter ausschließlich über TLS/HTTPS übertragen, niemals über unverschlüsselte Kanäle.
• Tokens und Passwörter nie in der URL mitsenden. OWASP wertet das Senden sensibler Auth-Details in der URL ausdrücklich als verwundbar; entsprechend gehören sie auch nicht in Logs.
• Kurzlebige Access-Tokens verwenden und über Refresh-Tokens erneuern. Laut oauth.net existiert das Refresh-Token genau dafür: Es erlaubt dem Authorization-Server kurze Token-Laufzeiten, ohne den Nutzer bei jedem Ablauf erneut einzubinden.
• Refresh-Tokens für öffentliche Clients absichern. Ein gestohlenes Refresh-Token eines Public-Clients lässt unbemerkten Missbrauch zu; eine Bindung an die Client-Instanz per DPoP wirkt dem entgegen. Sender-constrained Tokens verlangen den Besitznachweis eines privaten Schlüssels und sind so allein nicht nutzbar.

Token-Validierung serverseitig

• Tokens immer auf Authentizität prüfen. OWASP nennt fehlende Prüfung explizit als Schwachstelle.
• Unsignierte oder schwach signierte JWT ablehnen, insbesondere {"alg":"none"}.
• Das Ablaufdatum jedes JWT prüfen; abgelaufene Tokens zurückweisen.
• Laut oauth.net dürfen ID-Tokens nicht für Requests an den Resource-Server verwendet werden, und der Client darf den Inhalt des Access-Tokens nicht interpretieren. Das impliziert eine serverseitige Prüfung gegen die erwartete Audience.

Schutz gegen automatisierte Angriffe

• Rate Limiting, Account-Lockout und CAPTCHA gegen Brute-Force und Credential Stuffing. Achtung: OWASP zeigt, wie Angreifer per GraphQL-Query-Batching ein Pro-Request-Limit umgehen; das Limit muss also auch Batch-Operationen erfassen.
• Endpunkte für "Passwort vergessen / zurücksetzen" wie Login-Endpunkte behandeln (gleicher Brute-Force- und Rate-Limit-Schutz).
• Multi-Faktor-Authentifizierung einsetzen, wo möglich; schwache Passwörter unterbinden.
• Sensible Operationen wie Änderung von E-Mail oder Passwort an eine erneute Bestätigung des aktuellen Passworts koppeln, sonst ist Kontoübernahme über ein gestohlenes Token möglich.

Architektur und Prinzipien

• Authentifizierung, Token-Erzeugung und Passwort-Speicherung nicht selbst erfinden, sondern etablierte Standards nutzen (OAuth 2.0/2.1, OIDC, RFCs). OWASP betont zugleich: OAuth und API-Keys sind keine Authentifizierung an sich.
• Prinzip der minimalen Rechte: Ein Refresh-Token darf laut oauth.net keinen Zugriff über den Scope des ursprünglichen Grants hinaus gewähren.
• Schwache oder vorhersagbare Tokens und schwache Schlüssel vermeiden; Keys regelmäßig rotieren. In Microservice-Umgebungen darf kein Dienst ohne Authentifizierung erreichbar sein.
• Alle möglichen Auth-Flows (Web, Mobile, Deeplinks, One-Click) kennen und zentral, einheitlich prüfen.

POST /token grant_type=refresh_token&refresh_token=...&client_id=...

GET /api/orders
Authorization: Bearer <access_token>

=> { "access_token": "...", "expires_in": 900, "token_type": "Bearer" }

Kurzlebiges Access-Token via Refresh-Token erneuern, Token im Authorization-Header (nicht in der URL) senden

Authentifizierungsverfahren: Wann setzt man welches ein?

Die Wahl hängt davon ab, wer sich gegenüber wem ausweist (Mensch oder Maschine, Browser oder Service) und ob der Server Zustand halten soll. Grundsatz für alle Verfahren: Credentials und Token nur über TLS übertragen (OWASP, MDN).

API-Keys identifizieren eine Anwendung bzw. einen Service, nicht einen einzelnen Nutzer. Sie eignen sich für Server-zu-Server-Aufrufe, Rate-Limiting und Abrechnung pro Client.

• Geeignet: Maschinen-Identifikation, öffentliche/teilöffentliche APIs, Kontingentsteuerung.
• Nicht geeignet: echte Nutzerauthentifizierung, feingranulare Autorisierung; ein Key gilt als Bearer-Geheimnis und ist bei Leak voll missbrauchbar.
• Hinweis: serverseitig speichern, regelmäßig rotieren, nie im Frontend/Repo ablegen.

HTTP Basic sendet Benutzer und Passwort base64-kodiert im Authorization-Header (RFC 7617, Rahmenwerk RFC 7235). Einfach, aber das Geheimnis geht bei jeder Anfrage mit.

• Geeignet: interne Tools, Maschinenaufrufe, Schnelltests, immer nur über HTTPS/TLS.
• Nicht geeignet: öffentliche Endnutzer-Logins; base64 ist keine Verschlüsselung, ohne TLS völlig unsicher (MDN).

Session-Cookies sind das klassische Modell für serverseitige Browser-Apps: nach Login hält der Server die Session, der Browser sendet automatisch das Cookie.

• Geeignet: serverseitig gerenderte Web-Apps, einfaches sofortiges Invalidieren (Logout) über den Serverstate.
• Nicht geeignet: zustandslose APIs über viele Dienste, Cross-Domain- oder native-App-Szenarien ohne Browser.
• Hinweis: Cookies mit HttpOnly, Secure, SameSite setzen und CSRF-Schutz vorsehen.

Bearer-Token / JWT ermöglichen zustandslose, gut skalierbare Authentifizierung; der Token wird im Authorization: Bearer-Header mitgeschickt (RFC 6750, JWT RFC 7519).

• Geeignet: APIs, SPAs und Service-zu-Service-Kommunikation ohne gemeinsamen Sessionstore.
• Nicht geeignet: wenn sofortiges, zentrales Widerrufen kritisch ist; ein gestohlener Bearer-Token gilt bis zum Ablauf. Gegenmittel: kurze Laufzeit, Refresh-Token, Revocation/Introspection (RFC 7009, RFC 7662).

OAuth 2.0 / OIDC ist der Industriestandard für delegierten Zugriff: eine App erhält im Namen des Nutzers begrenzten Zugriff, ohne dessen Passwort zu kennen (oauth.net, RFC 6749). OpenID Connect ergänzt OAuth um den Identitäts- und Login-Layer (ID-Token).

• Geeignet: Drittanbieter-Zugriff, Single-Sign-On, Nutzer-Login über Identity-Provider, getrennte Scopes pro App.
• Nicht geeignet: als Overkill für simple interne Service-Aufrufe; falsche Flows sind ein Risiko.
• Hinweis: für Web-/SPA- und native Apps den Authorization-Code-Flow mit PKCE nutzen; Implicit- und Password-Grant gelten als veraltet (oauth.net, RFC 9700).

mTLS (Mutual TLS) authentifiziert beide Seiten über X.509-Zertifikate auf Transportebene (RFC 8705).

• Geeignet: gegenseitige Service-zu-Service-Authentifizierung, Zero-Trust-Netze, hochsichere OAuth-Varianten (Token-Bindung an Client-Zertifikat).
• Nicht geeignet: typische Endnutzer-Browser-Logins; Verteilung und Rotation der Zertifikate sind betrieblich aufwendig.

Faustregel: Maschine-zu-Maschine: API-Key oder mTLS bzw. Client-Credentials-Flow. Browser-App mit Server: Session-Cookies. API/SPA zustandslos: Bearer/JWT. Fremder Nutzer-Login oder delegierter Zugriff: OAuth 2.0 / OIDC.

// Bearer-Token im HTTP-Header (RFC 6750)
GET /api/orders HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...

// HTTP Basic (nur über TLS!) - RFC 7235
Authorization: Basic dXNlcjpwYXNzd29yZA==

Typischer Authorization-Header je nach Verfahren; Basic nur über HTTPS verwenden.

Quellen

• Authorization header - HTTP MDN Web Docs
• HTTP authentication MDN Web Docs
• OAuth 2.0 oauth.net (IETF OAuth Working Group)
• Authentication Cheat Sheet OWASP Cheat Sheet Series
• API2:2023 Broken Authentication OWASP API Security Top 10
• OAuth 2.0 Access Tokens oauth.net
• OAuth 2.0 Refresh Tokens oauth.net
• OAuth 2.0 Grant Types oauth.net