In modernen Webanwendungen ist Sicherheit ein entscheidender Aspekt, insbesondere für RESTful-APIs, die Zugriff auf sensible Ressourcen bieten. OAuth2 (Open Authorization) und JWT (JSON Web Tokens) sind zwei weit verbreitete Protokolle, um RESTful Web Services abzusichern.
Dieser Artikel erklärt, wie OAuth2 und JWT zusammenarbeiten, zeigt Codebeispiele zur Integration und präsentiert Statistiken sowie analytische Daten, um deren Einsatz zu begründen.
Warum OAuth2 und JWT für die Sicherheit von RESTful APIs verwenden?
- OAuth2: OAuth2 ist ein Autorisierungsframework, das es Drittanbieteranwendungen ermöglicht, auf die Ressourcen eines Nutzers zuzugreifen, ohne deren Anmeldedaten offenzulegen. Anstelle von Benutzernamen und Passwörtern nutzt OAuth2 Zugriffstokens, die in ihrem Umfang und ihrer Gültigkeitsdauer begrenzt sein können, was die Sicherheit verbessert.
- JWT: JSON Web Tokens (JWT) sind ein kompaktes, URL-sicheres Format zur Darstellung von Ansprüchen, die zwischen zwei Parteien ausgetauscht werden. JWTs sind eigenständig und enthalten Informationen wie Benutzerangaben, Ablaufdatum und mehr. Sie können digital signiert werden, um ihre Authentizität sicherzustellen.
Die Kombination von OAuth2 und JWT ermöglicht eine skalierbare und sichere Autorisierung in verteilten Systemen. So funktionieren diese beiden zusammen:
- Der Client fordert ein Zugriffstoken von einem OAuth2-Autorisierungsserver an.
- Der Server stellt ein JWT-Token aus, das der Client verwendet, um auf geschützte Ressourcen zuzugreifen.
- Der Server überprüft das JWT, um sicherzustellen, dass es nicht manipuliert wurde und weiterhin gültig ist.
Architektur Überblick
Die wichtigsten Akteure in dieser Architektur sind:
- Ressourcenbesitzer: Der Benutzer, der die Daten oder Ressourcen besitzt.
- Client: Die Anwendung, die Zugriff auf die Ressourcen anfordert.
- Autorisierungsserver: Gibt Tokens nach erfolgreicher Authentifizierung aus.
- Ressourcenserver: Hält die API oder Ressource und validiert das JWT-Token.
OAuth2 Grant-Typen
In OAuth2 ist ein Grant-Typ eine Methode, mit der ein Client (z. B. eine Web- oder Mobile-App) ein Zugriffstoken vom Autorisierungsserver erhält. Jeder Grant-Typ definiert einen spezifischen Ablauf, der es verschiedenen Client-Typen und Anwendungsfällen ermöglicht, Tokens auf sichere Weise anzufordern und zu erhalten. Die Wahl des richtigen Grant-Typs ist entscheidend, da er sowohl die Sicherheit als auch die Benutzerfreundlichkeit beeinflusst.
Es gibt mehrere OAuth2 Grant-Typen, aber für die meisten RESTful-APIs wird der Authorization Code Grant bevorzugt. Hier ist eine kurze Übersicht der am häufigsten verwendeten Grant-Typen:
- Authorization Code: Wird in Webanwendungen verwendet, bei denen der Client Client-Geheimnisse sicher handhaben kann.
- Client Credentials: Wird in der maschinen-zu-maschine (M2M) Kommunikation verwendet.
- Password: Direkter Austausch von Benutzername/Passwort gegen Tokens (nicht empfohlen für moderne Systeme).
Einrichten von OAuth2 und JWT in einer REST API
Sehen wir uns an, wie man eine RESTful API mit OAuth2 und JWT in einer typischen Node.js-Anwendung absichert. Wir verwenden Express.js zum Erstellen der REST API und das jsonwebtoken-Paket zur Handhabung von JWT.
Schritt 1: Erforderliche Bibliotheken installieren
Zuerst installieren Sie die notwendigen Pakete:
npm install express jsonwebtoken body-parser
Schritt 2: Erstellen des OAuth2-Autorisierungsservers
const express = require('express');
const jwt = require('jsonwebtoken');
const bodyParser = require('body-parser');
const app = express();
app.use(bodyParser.json());
const SECRET_KEY = 'your-secret-key'; // Use a strong secret key
const TOKEN_EXPIRATION = '1h'; // Token valid for 1 hour
// Mock user data for simplicity
const users = {
'user1': { password: 'password123' }
};
// Route to authenticate user and issue token
app.post('/oauth/token', (req, res) => {
const { username, password } = req.body;
if (users[username] && users[username].password === password) {
const token = jwt.sign({ username }, SECRET_KEY, { expiresIn: TOKEN_EXPIRATION });
return res.json({ access_token: token });
}
return res.status(401).json({ error: 'Invalid credentials' });
});
// Route to validate the token (protected resource)
app.get('/protected', (req, res) => {
const authHeader = req.headers['authorization'];
const token = authHeader && authHeader.split(' ')[1];
if (!token) return res.sendStatus(401);
jwt.verify(token, SECRET_KEY, (err, user) => {
if (err) return res.sendStatus(403);
return res.json({ message: 'Access granted', user });
});
});
app.listen(3000, () => {
console.log('Authorization server listening on port 3000');
});
In diesem Beispiel:
- Der Endpunkt /oauth/token authentifiziert den Benutzer und gibt ein JWT zurück, wenn die Anmeldedaten korrekt sind.
- Der Endpunkt /protected ist eine Ressource, die ein gültiges JWT erfordert, um darauf zuzugreifen.
Schritt 3: Client fordert Zugriffstoken an
Um auf die geschützte Ressource zuzugreifen, muss der Client zuerst ein Zugriffstoken vom Endpunkt /oauth/token anfordern:
curl -X POST http://localhost:3000/oauth/token -H "Content-Type: application/json" \
-d '{"username": "user1", "password": "password123"}'
Die Antwort enthält das Zugriffstoken:
{
"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}
Schritt 4: Zugriff auf die geschützte Ressource
Jetzt kann der Client das Zugriffstoken verwenden, um auf geschützte Ressourcen zuzugreifen:
curl -H "Authorization: Bearer <your-access-token>" http://localhost: 3000/protected
JWT-Struktur und Sicherheit
Ein JWT besteht aus drei Teilen: Header, Payload und Signature. Zum Beispiel:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6InVzZXIxIiwiaWF0IjoxNjE2NzAwMDAwLCJleHAiOjE2MTY3MzYwMDB9.abc123signature
- Header: Enthält Metadaten, typischerweise den Signaturalgorithmus (z. B. HS256).
- Payload: Enthält Claims, wie den Benutzernamen oder das Ablaufdatum.
- Signature: Stellt die Integrität des Tokens sicher.
Best Practices für JWT-Sicherheit:
- Ablauf: Setzen Sie immer ein Ablaufdatum (exp) für das Token, um seine Lebensdauer zu begrenzen.
- Signatur: Verwenden Sie starke geheime Schlüssel und signieren Sie Tokens mit robusten Algorithmen (z. B. RS256).
- HTTPS: Übertragen Sie Tokens immer über sicheres HTTPS, um Man-in-the-Middle (MITM)-Angriffe zu verhindern.
- Scopes: Begrenzen Sie Tokens nach Scope, um zu kontrollieren, welche Aktionen sie autorisieren können.
Erweiterte Architekturübersicht:
Autorisierungsserver: Verantwortlich für die Authentifizierung und das Erstellen von signierten Zugriffstokens (JWT) sowie Refresh-Tokens.
- Ressourcenserver: Hält die API und überprüft JWT-Tokens, um Anfragen basierend auf Scopes und Rollen zu autorisieren.
- Client: Das Frontend oder der Drittanbieterdienst, der mit der API und dem OAuth2-Server interagiert.
- Refresh Tokens: Werden verwendet, um ein neues Zugriffstoken zu erhalten, nachdem das alte abgelaufen ist, ohne dass der Benutzer sich erneut anmelden muss.
- Token-Blacklist: Mechanismus zum Widerrufen von Tokens nach deren Ausgabe (z. B. beim Logout).
Schritt 1: RSA Public/Private Key-Paar für JWT einrichten
Generieren Sie ein RSA-Schlüsselpaar, das zum Signieren und Überprüfen von JWT-Tokens verwendet wird. Der private Schlüssel wird vom Autorisierungsserver zum Signieren von Tokens verwendet, und der öffentliche Schlüssel wird vom Ressourcenserver zum Überprüfen der Tokens verwendet.
# Generate private key (RSA 2048-bit) openssl genrsa -out private.pem 2048 # Extract the public key from the private key openssl rsa -in private.pem -pubout -out public.pem
Schritt 2: Autorisierungsserver (OAuth2 + JWT mit RS256 Signierung)
Wir implementieren den Autorisierungsserver in Node.js mit Express und dem jsonwebtoken-Paket, unter Verwendung des OAuth2-Authorization-Code-Flows und der Token-Ausstellung.
const express = require('express');
const jwt = require('jsonwebtoken');
const fs = require('fs');
const bodyParser = require('body-parser');
const app = express();
app.use(bodyParser.json());
const PRIVATE_KEY = fs.readFileSync('private.pem', 'utf8'); // RSA Private Key
const PUBLIC_KEY = fs.readFileSync('public.pem', 'utf8'); // RSA Public Key
const TOKEN_EXPIRATION = '15m'; // Access token valid for 15 minutes
const REFRESH_TOKEN_EXPIRATION = '7d'; // Refresh token valid for 7 days
// Scopes and roles definition
const roles = {
'admin': ['read', 'write', 'delete'],
'user': ['read'],
};
// Mock user data
const users = {
'admin': { password: 'admin123', role: 'admin' },
'user': { password: 'user123', role: 'user' }
};
// Store refresh tokens (for example purposes, should be stored in DB in a real-world scenario
let refreshTokens = [];
// OAuth2 /authorize endpoint (Authorization Code Grant)
app.post('/oauth/token', (req, res) => {
const { username, password } = req.body;
// Validate user credentials
if (!users[username] || users[username].password !== password) {
return res.status(401).json({ error: 'Invalid credentials' });
}
const userRole = users[username].role;
const scopes = roles[userRole]; // Assign scope based on role
// Generate JWT (access token)
const accessToken = jwt.sign(
{ username, role: userRole, scope: scopes },
PRIVATE_KEY,
{ algorithm: 'RS256', expiresIn: TOKEN_EXPIRATION }
);
// Generate Refresh Token
const refreshToken = jwt.sign(
{ username, role: userRole },
PRIVATE_KEY,
{ algorithm: 'RS256', expiresIn: REFRESH_TOKEN_EXPIRATION }
);
// Store refresh token
refreshTokens.push(refreshToken);
res.json({ access_token: accessToken, refresh_token: refreshToken });
});
// Token revocation: Blacklist refresh tokens
app.post('/logout', (req, res) => {
const { refresh_token } = req.body;
// Revoke the refresh token
refreshTokens = refreshTokens.filter(token => token !== refresh_token);
res.json({ message: 'Logged out successfully' });
});
app.listen(4000, () => {
console.log('Authorization Server running on port 4000');
});
Schritt 3: Ressourcenserver (API mit JWT-Validierung)
Der Ressourcenserver ist verantwortlich für das Hosten der geschützten API-Endpunkte und die Validierung der von dem Autorisierungsserver ausgegebenen JWT-Zugriffstoken.
const express = require('express');
const jwt = require('jsonwebtoken');
const fs = require('fs');
const app = express();
const PUBLIC_KEY = fs.readFileSync('public.pem', 'utf8'); // RSA Public Key
// Middleware to validate JWT token and scopes
function authenticateToken(req, res, next) {
const authHeader = req.headers['authorization'];
const token = authHeader && authHeader.split(' ')[1];
if (!token) return res.sendStatus(401);
jwt.verify(token, PUBLIC_KEY, { algorithms: ['RS256'] }, (err, user) => {
if (err) return res.sendStatus(403); // Token is not valid
req.user = user; // Attach the decoded token (user info) to the request object
next();
});
}
// Middleware for scope checking
function authorize(scope) {
return (req, res, next) => {
if (!req.user.scope.includes(scope)) {
return res.sendStatus(403); // Forbidden
}
next();
};
}
// Protected API route (accessible only to users with 'read' scope)
app.get('/api/data', authenticateToken, authorize('read'), (req, res) => {
res.json({ data: 'Protected Data for User: ' + req.user.username });
});
// Another protected route (admin only, requiring 'delete' scope)
app.delete('/api/data', authenticateToken, authorize('delete'), (req, res) => {
res.json({ message: 'Data deleted by Admin: ' + req.user.username });
});
app.listen(3000, () => {
console.log('Resource Server running on port 3000');
});
Schritt 4: Client-Anforderungsfluss (Authorization Code Grant)
Hier ein Beispiel, wie ein Client sich authentifizieren und mit dem Ressourcenserver interagieren würde.
1. Der Client sendet zunächst Anmeldedaten an den Autorisierungsserver und erhält ein Zugriffstoken und ein Refresh-Token:
curl -X POST http://localhost:4000/oauth/token -H "Content-Type: application/json" \
-d '{"username": "admin", "password": "admin123"}'
Antwort:
{
"access_token": "<JWT_ACCESS_TOKEN>",
"refresh_token": "<JWT_REFRESH_TOKEN>"
}
2. Der Client sendet dann das Zugriffstoken, um auf eine geschützte Ressource zuzugreifen:
curl -H "Authorization: Bearer <JWT_ACCESS_TOKEN>" http://localhost:3000/api/data
3. Wenn das Zugriffstoken abgelaufen ist, kann der Client das Refresh-Token verwenden, um ein neues Zugriffstoken anzufordern, ohne die Anmeldedaten erneut einzugeben:
curl -X POST http://localhost:4000/oauth/token -H "Content-Type: application/json" \
-d '{"refresh_token": "<JWT_REFRESH_TOKEN>"}'
Schritt 5: Token-Blacklist (Logout-Verwaltung)
Um Tokens, insbesondere Refresh-Tokens, zu widerrufen, verfolgt der Autorisierungsserver die Refresh-Tokens. Beim Logout wird das Refresh-Token aus dem In-Memory-Speicher (oder der Datenbank in einer Produktionsumgebung) entfernt. Dies stellt sicher, dass der Benutzer dieses Refresh-Token nach dem Logout nicht mehr verwenden kann, um ein neues Zugriffstoken zu erhalten.
Beispielsweise kann der Client das Refresh-Token über folgenden Befehl widerrufen:
curl -X POST http://localhost:4000/logout -H "Content-Type: application/json" \
-d '{"refresh_token": "<JWT_REFRESH_TOKEN>"}'
Erwägungen zur Sicherheit
RSA vs HMAC (HS256 vs RS256): Die Verwendung von RS256 ist sicherer als HS256, da es öffentliche/private Schlüsselpaar ermöglicht. Der private Schlüssel signiert das Token, und der öffentliche Schlüssel wird mit dem Ressourcenserver zur Validierung geteilt, was unbefugtes Signieren verhindert.
- Token-Ablauf: Zugriffstoken sollten kurze Ablaufzeiten haben (z. B. 15 Minuten) und mit Refresh-Tokens erneuert werden. Dies reduziert die Auswirkungen eines kompromittierten Tokens.
- HTTPS: OAuth2-Kommunikation sollte immer über HTTPS durchgeführt werden, um Man-in-the-Middle (MITM)-Angriffe zu verhindern.
- Ablauf von Refresh-Tokens: Die Ablaufzeit des Refresh-Tokens sollte relativ kurz gehalten werden (z. B. einige Tage oder Wochen), und eine erneute Authentifizierung sollte für längere Perioden der Inaktivität erforderlich sein.
- Scopes und Rollen: Implementieren Sie eine feingranulare Zugriffskontrolle mit Scopes und Rollen. Im obigen Beispiel kann die Admin-Rolle Ressourcen löschen, während die Benutzerrolle nur auf diese zugreifen kann.
Analytische Daten und Statistiken
- Leistungsverbesserungen durch JWT: JWT ist zustandslos, was bedeutet, dass der Server keine Sitzungen speichern muss. Dies führt zu einer skalierbareren Architektur. Eine Studie von Okta fand heraus, dass die auf JWT basierende Autorisierung die Leistung um 30-50 % im Vergleich zur traditionellen sitzungsbasierten Authentifizierung verbessern kann, insbesondere in verteilten Mikrodiensten-Umgebungen.
- OAuth2-Adoption: Laut einem Bericht von Gartner aus dem Jahr 2023 ist OAuth2 der am weitesten verbreitete Autorisierungsrahmen, wobei 90 % der Fortune-500-Unternehmen OAuth2 in ihren Unternehmensanwendungen verwenden. Die Flexibilität und die Unterstützung für verschiedene Authentifizierungsflüsse machen es ideal für Web- und mobile Anwendungen.
-
Sicherheitsvorfälle: Der Verizon 2023 Data Breach Investigation Report hob hervor, dass eine unsachgemäße Sitzungsverwaltung, einschließlich unsicherer Token-Verwaltung, 20 % der Sicherheitsverletzungen bei Webanwendungen ausmachte. Dies unterstreicht die Notwendigkeit strenger Token-Validierungs- und Ablaufrichtlinien, die JWT unterstützt.
Fazit
Die Sicherung von RESTful Web Services mit OAuth2 und JWT bietet einen robusten, skalierbaren und effizienten Ansatz für moderne API-Sicherheit. Durch die Verwendung von OAuth2 für das Token-Management und JWT für zustandslose, eigenständige Token-Darstellung können Entwickler sichere APIs erstellen, die gut mit verteilten Systemen skalieren.
Für maximale Sicherheit ist es entscheidend, bewährte Praktiken wie die Verwendung von HTTPS, das Festlegen von Token-Ablaufzeiten und die Durchsetzung robuster Signaturalgorithmen zu befolgen. Mit zunehmender Akzeptanz und starken Leistungsverbesserungen werden OAuth2 und JWT eine Schlüsselrolle bei der Sicherung von Webanwendungen spielen.
