Modul 12 von 16 · 📖 8 min Lesezeit · ⏱ 30 min gesamt

FI-AE 12 Webentwicklung — HTTP, REST, OAuth

Inhaltsverzeichnis (6 Abschnitte)

Konzepte und Hintergrund
Architektur-Diagramm
Praktische Schritte
Häufige Fallstricke
Weiterführende Ressourcen
Wissens-Check

FI-AE 12 Webentwicklung — HTTP, REST, OAuth

Das Modul vermittelt die Grundlagen der Webkommunikation mit Fokus auf HTTP-Protokoll, REST-Architektur und moderne Authentifizierungsverfahren. Sie lernen die Request/Response-Zyklen zu verstehen, RESTful Services zu entwerfen und sicherzustellen, dass Ihre Anwendungen durch OAuth 2.0 und OpenID Connect geschützt sind.

Praktische Anwendung der Konzepte steht im Vordergrund: Von der Implementierung von JWTs bis zum Aufbau von API-Sicherheit. Nach Abschluss dieses Moduls können Sie robuste, skalierbare Webanwendungen entwickeln, die moderne Sicherheitsstandards erfüllen.

Konzepte und Hintergrund

HTTP (Hypertext Transfer Protocol): Das Standardprotokoll für die Übertragung von Daten im World Wide Web. Definiert Request/Response-Methoden (GET, POST, PUT, DELETE) und Statuscodes (200 OK, 404 Not Found, 500 Internal Server Error).
REST (Representational State Transfer): Ein Architekturstil für verteilte Systeme, der auf dem HTTP-Protokoll aufbaut. RESTful Services nutzen URI-Ressourcen, Standardmethoden und zustandslose Kommunikation. Die Prinzipien sind Client-Server, Stateless, Cacheable, Uniform Interface und Layered System.
OAuth 2.0: Ein Autorisierungsframework, das Clients den Zugriff auf Benutzerdaten gewährt, ohne Anmeldeinformationen weiterzugeben. Definiert vier Haupt-Flows: Authorization Code, Implicit, Resource Owner Password Credentials und Client Credentials.
JWT (JSON Web Token): Ein kompakter, URL-sicherer Token-Standard zur Übertragung von Informationen zwischen Parteien. Besteht aus Header, Payload und Signature, die durch einen Punkt getrennt sind. Wird häufig für Authentifizierung und Informationsaustausch in OAuth 2.0 verwendet.
OpenID Connect (OIDC): Eine Identitätsschicht auf Basis von OAuth 2.0. Ermöglicht Clients die Identität eines Nutzers zu verifizieren und grundlegende Profilinformationen zu erhalten. Baut auf dem OAuth 2.0 Authorization Code Flow auf.

Architektur-Diagramm

sequenceDiagram
    participant K as Client (Webseite)
    participant A as Authentifizierungsserver
    participant R as Ressourcenserver (API)
    
    K->>A: 1. Anfrage mit Client-ID und Redirect URI
    A->>K: 2. Weiterleitung zur Login-Seite
    K->>A: 3. Login mit Benutzername/Passwort
    A->>K: 4. Authorization Code
    K->>A: 5. Token-Anfrage mit Code
    A->>K: 6. Access Token + ID Token
    K->>R: 7. API-Request mit Access Token
    R->>K: 8. Geschützte Ressource

Praktische Schritte

HTTP-Grundlagen verstehen: Verwenden Sie curl, um verschiedene HTTP-Methoden zu testen.
```
curl -X GET https://api.example.com/users
```
Dies demonstriert eine einfache Ressourcenanfrage.
RESTful API-Endpunkte entwerfen: Strukturieren Sie Ihre Ressourcen hierarchisch und verwenden Sie HTTP-Methoden semantisch korrekt.
```
POST /api/orders
{
  "customer_id": 123,
  "items": [{"product_id": 456, "quantity": 2}]
}
```
Erstellt eine neue Bestellung.
OAuth 2.0 Authorization Code Flow implementieren: Richten Sie einen Redirect URI in Ihrer Client-Anwendung ein und implementieren Sie die Token-Austauschlogik.
JWT validieren: Überprüfen Sie bei jedem eingehenden Request die Signatur und die Ablaufzeit des Tokens.
```
jwt.verify(token, 'your-secret-key', (err, decoded) => {
  if (err) throw new Error('Ungültiges Token');
  console.log(decoded);
});
```
Stellt sicher, dass das Token authentisch ist.
CORS konfigurieren: Ermöglichen Sie Cross-Origin-Anfragen für Ihre API, indem Sie die entsprechenden Header setzen.
```
Access-Control-Allow-Origin: https://your-client-domain.com
Access-Allow-Credentials: true
```
Erlaubt sichere Anfragen von anderen Domains.
API-Sicherheit implementieren: Schützen Sie sensible Endpunkte mit Middleware, die den Access Token validiert.
```
app.use('/api/protected', authenticateToken, (req, res) => {
  res.json({ message: 'Zugriff gewährt' });
});
```
Stellt sicher, dass nur authentifizierte Nutzer geschützte Ressourcen erreichen.

Häufige Fallstricke

Weiterführende Ressourcen

Wissens-Check

Vier Fragen zur Selbstkontrolle. Klicken Sie jede Frage an, um die richtige Antwort und Erklärung zu sehen.

Welches der folgenden Prinzipien ist kein Kernprinzip des REST-Architekturstils?

A) Stateless
B) Cacheable
C) Stateful
D) Uniform Interface

Richtige Antwort: C. Stateful (zustandsbehaftet) ist im Gegensatz zu Stateless ein Prinzip, das REST bewusst vermeidet, um die Skalierbarkeit zu erhöhen.

Was ist der Hauptunterschied zwischen OAuth 2.0 und OpenID Connect?

A) OAuth 2.0 ist für die Authentifizierung, OpenID Connect für die Autorisierung
B) OpenID Connect baut auf OAuth 2.0 auf und fügt eine Identitätsschicht hinzu
C) OAuth 2.0 erfordert immer JWTs, OpenID Connect nicht
D) OpenID Connect ist nur für mobile Anwendungen geeignet

Richtige Antwort: B. OpenID Connect ist eine Erweiterung von OAuth 2.0, die speziell zur Authentifizierung von Benutzern entwickelt wurde, während OAuth 2.0 primär für die Autorisierung dient.

Welcher HTTP-Statuscode signalisiert erfolgreich, dass eine Anfrage entgegengenommen und verarbeitet wurde, aber keine Informationen zurückgegeben hat?

A) 200 OK
B) 201 Created
C) 204 No Content
D) 304 Not Modified

Richtige Antwort: C. Der Statuscode 204 No Content wird verwendet, wenn die Anfrage erfolgreich war, aber der Server keine Daten zurücksendet, z.B. nach einer DELETE-Anfrage.

Welcher OAuth 2.0 Flow ist am besten für Single-Page-Anwendungen geeignet, die keine Server-seitige Komponente haben?

A) Authorization Code Flow
B) Implicit Flow
C) Resource Owner Password Credentials Flow
D) Client Credentials Flow

Richtige Antwort: B. Der Implicit Flow ist für Single-Page-Anwendungen optimiert, da er direkt ein Token zurückgibt, ohne einen Server-seitigen Code Exchange zu benötigen.