Zum Hauptinhalt springen

RFC 7235 - HTTP/1.1: Authentifizierung (Authentication)

  • Status: Proposed Standard
  • Veröffentlicht: June 2014
  • Stream: IETF
  • Ersetzt: RFC2616, RFC2617
  • Ersetzt durch: RFC9110
  • Errata: Keine Errata

Dokumentinformationen​

  • RFC-Nummer: 7235
  • Titel: Hypertext Transfer Protocol (HTTP/1.1): Authentication
  • Titel (Deutsch): Hypertext Transfer Protocol (HTTP/1.1): Authentifizierung
  • Veröffentlichungsdatum: Juni 2014
  • Autoren: R. Fielding (Adobe), J. Reschke (greenbytes)
  • Ersetzt Dokument: RFC 2616, RFC 2617 (teilweise)
  • Status: Standards Track

Zusammenfassung​

HTTP bietet ein einfaches Challenge-Response-Authentifizierungsframework, bei dem Server Client-Anfragen herausfordern können und Clients Authentifizierungsinformationen bereitstellen können. Dieses Dokument definiert den allgemeinen Mechanismus des HTTP-Authentifizierungsframeworks, einschließlich der Statuscodes 401, 407 und verwandter Header-Felder.

Kernkonzepte​

HTTP-Authentifizierungsablauf​

1. Client fordert geschützte Ressource an
   → GET /admin HTTP/1.1

2. Server gibt Challenge zurück
   ← HTTP/1.1 401 Unauthorized
     WWW-Authenticate: Basic realm="Admin Area"

3. Client liefert Anmeldedaten
   → GET /admin HTTP/1.1
     Authorization: Basic dXNlcjpwYXNzd29yZA==

4. Server verifiziert und antwortet
   ← HTTP/1.1 200 OK
     [Geschützter Inhalt...]

Authentifizierungsschemata (Authentication Schemes)​

HTTP unterstützt mehrere Authentifizierungsschemata:

  • Basic: Basisauthentifizierung (RFC 7617)
  • Bearer: Bearer-Token (RFC 6750)
  • Digest: Digest-Authentifizierung (RFC 7616)
  • OAuth: OAuth-Authentifizierung (RFC 6749)

401 Unauthorized​

Zeigt an, dass die Anfrage keine gültigen Authentifizierungsinformationen enthält.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="WallyWorld"
Content-Type: text/html
Content-Length: 0

Wichtig: Der Name "Unauthorized" von 401 bedeutet tatsächlich Unauthenticated (Nicht authentifiziert).

407 Proxy Authentication Required​

Zeigt an, dass der Client sich zuerst beim Proxy authentifizieren muss.

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Proxy Access"

WWW-Authenticate Header​

Der Server verwendet diesen Header, um eine Authentifizierungs-Challenge zu definieren.

Grundlegende Syntax​

WWW-Authenticate: &lt;scheme> realm="&lt;realm>" [, <param>=&lt;value>]*

Beispiele​

Einzelne Challenge:

WWW-Authenticate: Basic realm="Admin Area"

Mehrere Challenges (Client kann wählen):

WWW-Authenticate: Bearer realm="API", Basic realm="API"

Mit zusätzlichen Parametern:

WWW-Authenticate: Digest
    realm="[email protected]",
    qop="auth,auth-int",
    nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
    opaque="5ccc069c403ebaf9f0171e9517f40e41"

realm-Parameter​

realm (Bereich) definiert den Umfang des geschützten Raums:

WWW-Authenticate: Basic realm="Administratorbereich"
  • Wird normalerweise im Authentifizierungsdialog des Browsers angezeigt
  • Hilft Benutzern zu verstehen, welche Anmeldedaten erforderlich sind
  • Ressourcen mit demselben realm teilen sich Anmeldedaten

Authorization Header​

Der Client verwendet diesen Header, um Authentifizierungsinformationen bereitzustellen.

Grundlegende Syntax​

Authorization: &lt;scheme> &lt;credentials>

Beispiele​

Basic-Authentifizierung:

Authorization: Basic dXNlcjpwYXNzd29yZA==

Bearer-Token:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Digest-Authentifizierung:

Authorization: Digest username="user",
    realm="[email protected]",
    nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
    uri="/dir/index.html",
    response="6629fae49393a05397450978507c4ef1"

Proxy-Authenticate und Proxy-Authorization​

Werden für Proxy-Authentifizierung verwendet und funktionieren ähnlich wie WWW-Authenticate und Authorization.

Proxy-Authentifizierungsablauf​

1. Client-Anfrage
   → GET http://example.com/ HTTP/1.1

2. Proxy fordert Authentifizierung
   ← HTTP/1.1 407 Proxy Authentication Required
     Proxy-Authenticate: Basic realm="Proxy"

3. Client liefert Anmeldedaten
   → GET http://example.com/ HTTP/1.1
     Proxy-Authorization: Basic cHJveHk6cGFzc3dvcmQ=

4. Proxy leitet Anfrage weiter
   [Proxy] → GET / HTTP/1.1
            Host: example.com

Basic-Authentifizierung (RFC 7617)​

Das einfachste, aber unsicherste Authentifizierungsschema.

Anmeldedaten kodieren​

// 1. Benutzername und Passwort kombinieren
const credentials = "username:password";

// 2. Base64-Kodierung
const encoded = btoa(credentials);
// Ergebnis: "dXNlcm5hbWU6cGFzc3dvcmQ="

// 3. Authorization-Header erstellen
const auth = `Basic ${encoded}`;

Vollständiges Beispiel​

GET /admin HTTP/1.1
Host: example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Sicherheitswarnung​

Gefahr: Basic-Authentifizierung überträgt Anmeldedaten Base64-kodiert, das ist keine Verschlüsselung!

dXNlcm5hbWU6cGFzc3dvcmQ= 
  ↓ Base64-Dekodierung
username:password

HTTPS muss verwendet werden:

✗ http://example.com + Basic-Auth = Klartext-Übertragung
✓ https://example.com + Basic-Auth = Verschlüsselte Übertragung

Bearer-Token-Authentifizierung (RFC 6750)​

Ein häufig verwendetes Authentifizierungsschema für moderne Web-APIs.

Verwendungsszenarien​

Wird normalerweise mit OAuth 2.0 verwendet:

1. Benutzer meldet sich an, erhält Zugriffstoken
   ← { "access_token": "eyJhbG...", "token_type": "Bearer" }

2. Token verwenden, um auf API zuzugreifen
   → GET /api/user HTTP/1.1
     Authorization: Bearer eyJhbG...

Beispiel​

GET /api/resource HTTP/1.1
Host: api.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

Fehlerantwort​

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="API",
                  error="invalid_token",
                  error_description="The access token expired"

Digest-Authentifizierung (RFC 7616)​

Sicherer als Basic, aber komplexer.

Merkmale​

  • Überträgt Passwort nicht direkt
  • Verwendet Challenge-Response-Mechanismus
  • Verhindert Replay-Angriffe (durch nonce)

Vereinfachter Ablauf​

1. Server sendet Challenge (mit nonce)
   ← WWW-Authenticate: Digest realm="...", nonce="..."

2. Client berechnet Antwort
   response = MD5(
       MD5(username:realm:password) :
       nonce :
       MD5(method:uri)
   )

3. Client sendet Antwort
   → Authorization: Digest username="...", response="..."

Praktische Anwendungsszenarien​

Szenario 1: Webanwendungsanmeldung​

Traditionelles Formular + Session (empfohlen):

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded

username=user&password=pass

→ HTTP/1.1 302 Found
  Set-Cookie: sessionid=abc123; HttpOnly; Secure

HTTP Basic-Auth nicht verwenden (es sei denn über HTTPS).

Szenario 2: API-Authentifizierung​

Bearer Token (empfohlen):

GET /api/users HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Szenario 3: Verwaltungsoberfläche schützen​

Basic-Auth + HTTPS (einfache Szenarien):

GET /admin HTTP/1.1
Host: secure.example.com
Authorization: Basic YWRtaW46c2VjcmV0

Szenario 4: Microservice-Authentifizierung​

Mutual TLS + Bearer Token:

GET /internal/service HTTP/1.1
Host: internal.example.com
Authorization: Bearer service-token-123

Authentifizierung vs. Autorisierung​

Unterschied​

Authentifizierung (Authentication): "Wer bist du?"

Authorization: Bearer [Identitätstoken]

Autorisierung (Authorization): "Was darfst du tun?"

Im Token enthaltene Berechtigungen:
{
  "user_id": "123",
  "roles": ["admin", "editor"],
  "permissions": ["read", "write", "delete"]
}

HTTP-Statuscodes​

  • 401 Unauthorized: Authentifizierung fehlgeschlagen oder fehlt
  • 403 Forbidden: Authentifizierung erfolgreich, aber keine Berechtigung
Benutzer A versucht auf Admin-Ressource zuzugreifen:
→ Nicht angemeldet → 401 Unauthorized
→ Angemeldet (normaler Benutzer) → 403 Forbidden
→ Angemeldet (Administrator) → 200 OK

Best Practices​

Serverseitig​

  1. Immer HTTPS verwenden

    ✓ https://api.example.com
    ✗ http://api.example.com

  2. Klares realm bereitstellen

    WWW-Authenticate: Bearer realm="My API v1"

  3. Mehrere Authentifizierungsschemata unterstützen

    WWW-Authenticate: Bearer realm="API", Basic realm="API"

  4. Fehlgeschlagene Versuche begrenzen

    • Rate Limiting implementieren
    • Fehlgeschlagene Authentifizierungsversuche protokollieren
    • Temporäres Sperren von Konten erwägen

  5. Anmeldedaten sicher speichern

    • Passwörter mit starkem Hashing (bcrypt, Argon2)
    • Token mit sicherem Zufallsgenerator

Clientseitig​

  1. Token sicher speichern

    // ✓ Empfohlen
    sessionStorage.setItem('token', token);

    // ✗ Vermeiden (XSS-Risiko)
    localStorage.setItem('token', token);

  2. 401-Antworten behandeln

    if (response.status === 401) {
        // Lokales Token löschen
        // Zur Anmeldeseite umleiten
    }

  3. Token-Aktualisierung

    // Token automatisch aktualisieren, bevor es abläuft
    if (tokenExpiresIn &lt; 5 * 60) {
        refreshToken();
    }

Sicherheitsüberlegungen​

1. Man-in-the-Middle-Angriffe​

Risiko: Unverschlüsselte Übertragung von Anmeldedaten

Verteidigung: HTTPS verwenden

✗ HTTP + Basic: Klartext-Anmeldedaten gestohlen
✓ HTTPS + Basic: Verschlüsselte Übertragung, sicher

2. Replay-Angriffe​

Risiko: Angreifer fangen Authentifizierungsanfragen ab und spielen sie erneut ab

Verteidigung:

  • Kurzlebige Token verwenden
  • Nonce-Mechanismus implementieren
  • Token an bestimmten Client binden

3. Anmeldedaten-Lecks​

Risiko: Anmeldedaten werden protokolliert oder geleakt

Verteidigung:

  • Anmeldedaten nicht in URL übergeben
  • Kurzlebige Zugriffstoken verwenden
  • Refresh-Token-Mechanismus implementieren
✗ https://api.example.com/data?token=abc123
✓ Authorization: Bearer abc123

4. XSS-Angriffe​

Risiko: Bösartige Skripte stehlen Token

Verteidigung:

  • HttpOnly-Cookies verwenden
  • CSP-Richtlinien implementieren
  • Eingaben validieren und bereinigen

Zusammenfassung​

HTTP-Authentifizierung bietet ein flexibles Framework:

  • Vertrauen: Authentifizierungsprotokolle präzise implementieren, Sicherheit gewährleisten
  • Klarheit: Authentifizierungsanforderungen klar ausdrücken, Client-Implementierung erleichtern
  • Eleganz: Authentifizierungsabläufe elegant gestalten, Benutzererfahrung verbessern

Kernprinzipien:

  1. Immer HTTPS verwenden
  2. Geeignetes Authentifizierungsschema für Szenario wählen
  3. Defense-in-Depth-Strategie implementieren
  4. Anmeldedaten regelmäßig rotieren

Moderne Empfehlungen:

  • Webanwendungen: OAuth 2.0 + OpenID Connect
  • API: Bearer Token (JWT)
  • Einfache Szenarien: Basic + HTTPS
  • Vermeiden: Digest (veraltet und komplex)

Verwandte Dokumente:

  • RFC 7617: Basic-Authentifizierung
  • RFC 7616: Digest-Authentifizierung
  • RFC 6750: Bearer Token
  • RFC 6749: OAuth 2.0

Zurück zur HTTP/1.1-Serie