Schütze deine Django REST Framework API mit rollenbasierter Zugangskontrolle (RBAC) und JWT-Validierung
Diese Anleitung hilft dir, Autorisierung zu implementieren, um deine Django REST Framework APIs mit rollenbasierter Zugangskontrolle (RBAC) und JSON Web Tokens (JWTs), die von Logto ausgestellt werden, abzusichern.
Bevor du beginnst
Deine Client-Anwendungen müssen Zugangstokens (Access tokens) von Logto erhalten. Falls du die Client-Integration noch nicht eingerichtet hast, schaue dir unsere Schnellstarts für React, Vue, Angular oder andere Client-Frameworks an oder sieh dir unseren Maschine-zu-Maschine-Leitfaden für Server-zu-Server-Zugriff an.
Dieser Leitfaden konzentriert sich auf die serverseitige Validierung dieser Tokens in deiner Django REST Framework-Anwendung.

Was du lernen wirst
- JWT-Validierung: Lerne, Zugangstokens (Access tokens) zu validieren und Authentifizierungsinformationen zu extrahieren
- Middleware-Implementierung: Erstelle wiederverwendbare Middleware zum Schutz deiner API
- Berechtigungsmodelle: Verstehe und implementiere verschiedene Autorisierungsmuster (Authorization patterns):
- Globale API-Ressourcen für anwendungsweite Endpunkte
- Organisationsberechtigungen für mandantenspezifische Funktionskontrolle
- Organisationsbezogene API-Ressourcen für Multi-Tenant-Datenzugriff
- RBAC-Integration: Erzwinge rollenbasierte Berechtigungen (Role-based permissions) und Berechtigungen (Scopes) in deinen API-Endpunkten
Voraussetzungen
- Neueste stabile Version von Python installiert
- Grundlegendes Verständnis von Django REST Framework und Web-API-Entwicklung
- Eine konfigurierte Logto-Anwendung (siehe Schnellstarts, falls benötigt)
Überblick über Berechtigungsmodelle
Bevor du Schutzmechanismen implementierst, wähle das Berechtigungsmodell, das zu deiner Anwendungsarchitektur passt. Dies steht im Einklang mit den drei Haupt-Autorisierungsszenarien von Logto:
- Globale API-Ressourcen
- Organisations-(Nicht-API-)Berechtigungen
- Organisationsbezogene API-Ressourcen

- Anwendungsfall: Schutz von API-Ressourcen, die in deiner gesamten Anwendung geteilt werden (nicht organisationsspezifisch)
- Token-Typ: Zugangstoken (Access token) mit globaler Zielgruppe (Audience)
- Beispiele: Öffentliche APIs, Kernproduktdienste, Admin-Endpunkte
- Am besten geeignet für: SaaS-Produkte mit APIs, die von allen Kunden genutzt werden, Microservices ohne Mandantenisolation
- Mehr erfahren: Globale API-Ressourcen schützen

- Anwendungsfall: Steuerung von organisationsspezifischen Aktionen, UI-Funktionen oder Geschäftslogik (keine APIs)
- Token-Typ: Organisationstoken mit organisationsspezifischer Zielgruppe (Audience)
- Beispiele: Feature-Gating, Dashboard-Berechtigungen, Steuerung von Mitglieder-Einladungen
- Am besten geeignet für: Multi-Tenant-SaaS mit organisationsspezifischen Funktionen und Workflows
- Mehr erfahren: Organisations-(Nicht-API-)Berechtigungen schützen

- Anwendungsfall: Schutz von API-Ressourcen, die innerhalb eines bestimmten Organisationskontextes zugänglich sind
- Token-Typ: Organisationstoken mit API-Ressourcen-Zielgruppe (Audience) + Organisationskontext
- Beispiele: Multi-Tenant-APIs, organisationsbezogene Datenendpunkte, mandantenspezifische Microservices
- Am besten geeignet für: Multi-Tenant-SaaS, bei denen API-Daten organisationsbezogen sind
- Mehr erfahren: Organisationsbezogene API-Ressourcen schützen
💡 Wähle dein Modell, bevor du fortfährst – die Umsetzung in diesem Leitfaden bezieht sich durchgehend auf deinen gewählten Ansatz.
Schnelle Vorbereitungsschritte
Logto-Ressourcen & Berechtigungen konfigurieren
- Globale API-Ressourcen
- Organisations-(Nicht-API-)Berechtigungen
- Organisationsbezogene API-Ressourcen
- API-Ressource erstellen: Gehe zu Konsole → API-Ressourcen und registriere deine API (z. B.
https://api.yourapp.com
) - Berechtigungen definieren: Füge Berechtigungen wie
read:products
,write:orders
hinzu – siehe API-Ressourcen mit Berechtigungen definieren - Globale Rollen erstellen: Gehe zu Konsole → Rollen und erstelle Rollen, die deine API-Berechtigungen enthalten – siehe Globale Rollen konfigurieren
- Rollen zuweisen: Weisen Sie Benutzern oder M2M-Anwendungen, die API-Zugriff benötigen, Rollen zu
- Organisationsberechtigungen definieren: Erstelle nicht-API-bezogene Organisationsberechtigungen wie
invite:member
,manage:billing
in der Organisationstemplate - Organisationsrollen einrichten: Konfiguriere die Organisationstemplate mit organisationsspezifischen Rollen und weise ihnen Berechtigungen zu
- Organisationsrollen zuweisen: Weisen Sie Benutzern innerhalb jedes Organisationskontexts Organisationsrollen zu
- API-Ressource erstellen: Registriere deine API-Ressource wie oben, aber sie wird im Organisationskontext verwendet
- Berechtigungen definieren: Füge Berechtigungen wie
read:data
,write:settings
hinzu, die auf den Organisationskontext beschränkt sind - Organisationstemplate konfigurieren: Richte Organisationsrollen ein, die deine API-Ressourcenberechtigungen enthalten
- Organisationsrollen zuweisen: Weisen Sie Benutzern oder M2M-Anwendungen Organisationsrollen zu, die API-Berechtigungen enthalten
- Multi-Tenant-Setup: Stelle sicher, dass deine API organisationsbezogene Daten und Validierung verarbeiten kann
Beginne mit unserem Leitfaden zur rollenbasierten Zugangskontrolle (RBAC) für eine Schritt-für-Schritt-Anleitung.
Aktualisiere deine Client-Anwendung
Fordere die passenden Berechtigungen in deinem Client an:
- Benutzer-Authentifizierung: App aktualisieren →, um deine API-Berechtigungen und/oder Organisationskontext anzufordern
- Maschine-zu-Maschine: M2M-Berechtigungen konfigurieren → für Server-zu-Server-Zugriff
Der Prozess beinhaltet in der Regel die Aktualisierung deiner Client-Konfiguration, um eines oder mehrere der folgenden Elemente einzuschließen:
scope
-Parameter in OAuth-Flowsresource
-Parameter für den Zugriff auf API-Ressourcenorganization_id
für den Organisationskontext
Stelle sicher, dass der Benutzer oder die M2M-App, die du testest, die entsprechenden Rollen oder Organisationsrollen zugewiesen bekommen hat, die die notwendigen Berechtigungen für deine API enthalten.
Initialisiere dein API-Projekt
Um ein neues Django REST Framework-Projekt zu initialisieren:
django-admin startproject your_api_name
cd your_api_name
Installiere die benötigten Pakete:
pip install Django djangorestframework
Erstelle eine grundlegende Django-App:
python manage.py startapp api
Füge DRF zu den Einstellungen hinzu:
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'rest_framework',
'api',
]
Erstelle eine grundlegende API-View:
from rest_framework.decorators import api_view
from rest_framework.response import Response
@api_view(['GET'])
def hello_view(request):
return Response({"message": "Hello from Django REST Framework"})
Füge die URL-Konfiguration hinzu:
from django.urls import path
from . import views
urlpatterns = [
path('', views.hello_view, name='hello'),
]
from django.contrib import admin
from django.urls import path, include
urlpatterns = [
path('admin/', admin.site.urls),
path('api/', include('api.urls')),
]
Starte den Entwicklungsserver:
python manage.py runserver
Weitere Informationen zur Einrichtung von Serializern, Viewsets und anderen Funktionen findest du in der Django REST Framework-Dokumentation.
Initialisiere Konstanten und Hilfsfunktionen
Definiere die notwendigen Konstanten und Hilfsfunktionen in deinem Code, um die Extraktion und Validierung von Tokens zu handhaben. Eine gültige Anfrage muss einen Authorization
-Header in der Form Bearer <Zugangstoken (Access token)>
enthalten.
JWKS_URI = 'https://your-tenant.logto.app/oidc/jwks'
ISSUER = 'https://your-tenant.logto.app/oidc'
class AuthInfo:
def __init__(self, sub: str, client_id: str = None, organization_id: str = None,
scopes: list = None, audience: list = None):
self.sub = sub
self.client_id = client_id
self.organization_id = organization_id
self.scopes = scopes or []
self.audience = audience or []
def to_dict(self):
return {
'sub': self.sub,
'client_id': self.client_id,
'organization_id': self.organization_id,
'scopes': self.scopes,
'audience': self.audience
}
class AuthorizationError(Exception):
def __init__(self, message: str, status: int = 403):
self.message = message
self.status = status
super().__init__(self.message)
def extract_bearer_token_from_headers(headers: dict) -> str:
"""
Extrahiere das Bearer-Token aus den HTTP-Headern.
Hinweis: FastAPI und Django REST Framework verfügen über eine eingebaute Token-Extraktion,
daher ist diese Funktion hauptsächlich für Flask und andere Frameworks gedacht.
"""
authorization = headers.get('authorization') or headers.get('Authorization')
if not authorization:
raise AuthorizationError('Authorization-Header fehlt', 401)
if not authorization.startswith('Bearer '):
raise AuthorizationError('Authorization-Header muss mit "Bearer " beginnen', 401)
return authorization[7:] # Entferne das Präfix 'Bearer '
Informationen über deinen Logto-Mandanten abrufen
Du benötigst die folgenden Werte, um von Logto ausgestellte Tokens zu validieren:
- JSON Web Key Set (JWKS) URI: Die URL zu den öffentlichen Schlüsseln von Logto, die zur Überprüfung von JWT-Signaturen verwendet wird.
- Aussteller (Issuer): Der erwartete Ausstellerwert (die OIDC-URL von Logto).
Zuerst finde den Endpunkt deines Logto-Tenants. Du findest ihn an verschiedenen Stellen:
- In der Logto-Konsole unter Einstellungen → Domains.
- In den Anwendungseinstellungen, die du in Logto konfiguriert hast, unter Einstellungen → Endpoints & Credentials.
Abrufen vom OpenID Connect Discovery-Endpunkt
Diese Werte können vom OpenID Connect Discovery-Endpunkt von Logto abgerufen werden:
https://<your-logto-endpoint>/oidc/.well-known/openid-configuration
Hier ist ein Beispiel für eine Antwort (andere Felder wurden zur Übersichtlichkeit weggelassen):
{
"jwks_uri": "https://your-tenant.logto.app/oidc/jwks",
"issuer": "https://your-tenant.logto.app/oidc"
}
Im Code fest hinterlegen (nicht empfohlen)
Da Logto keine Anpassung der JWKS-URI oder des Ausstellers (Issuer) erlaubt, kannst du diese Werte fest in deinem Code hinterlegen. Dies wird jedoch für Produktionsanwendungen nicht empfohlen, da dies den Wartungsaufwand erhöhen kann, falls sich zukünftig Konfigurationen ändern.
- JWKS URI:
https://<your-logto-endpoint>/oidc/jwks
- Aussteller (Issuer):
https://<your-logto-endpoint>/oidc
Token und Berechtigungen validieren
Nach dem Extrahieren des Tokens und dem Abrufen der OIDC-Konfiguration überprüfe Folgendes:
- Signatur: JWT muss gültig und von Logto (über JWKS) signiert sein.
- Aussteller (Issuer): Muss mit dem Aussteller deines Logto-Tenants übereinstimmen.
- Zielgruppe (Audience): Muss mit dem in Logto registrierten Ressourcenindikator der API oder dem Organisationskontext (falls zutreffend) übereinstimmen.
- Ablauf (Expiration): Token darf nicht abgelaufen sein.
- Berechtigungen (Scopes): Token muss die erforderlichen Berechtigungen für deine API / Aktion enthalten. Berechtigungen sind durch Leerzeichen getrennte Zeichenfolgen im
scope
-Anspruch. - Organisationskontext: Wenn du API-Ressourcen auf Organisationsebene schützt, überprüfe den
organization_id
-Anspruch.
Siehe JSON Web Token, um mehr über die Struktur und Ansprüche von JWT zu erfahren.
Was bei jedem Berechtigungsmodell zu prüfen ist
- Globale API-Ressourcen
- Organisation (nicht-API) Berechtigungen
- API-Ressourcen auf Organisationsebene
- Audience-Anspruch (
aud
): API-Ressourcenindikator - Organisations-Anspruch (
organization_id
): Nicht vorhanden - Zu prüfende Berechtigungen (
scope
): API-Ressourcen-Berechtigungen
- Audience-Anspruch (
aud
):urn:logto:organization:<id>
(Organisationskontext ist imaud
-Anspruch) - Organisations-Anspruch (
organization_id
): Nicht vorhanden - Zu prüfende Berechtigungen (
scope
): Organisationsberechtigungen
- Audience-Anspruch (
aud
): API-Ressourcenindikator - Organisations-Anspruch (
organization_id
): Organisations-ID (muss mit Anfrage übereinstimmen) - Zu prüfende Berechtigungen (
scope
): API-Ressourcen-Berechtigungen
Für nicht-API-Organisationsberechtigungen wird der Organisationskontext durch den aud
-Anspruch
dargestellt (z. B. urn:logto:organization:abc123
). Der organization_id
-Anspruch ist nur für
Tokens von API-Ressourcen auf Organisationsebene vorhanden.
Validiere immer sowohl Berechtigungen (Scopes) als auch Kontext (Audience, Organisation) für sichere Multi-Tenant-APIs.
Validierungslogik hinzufügen
Wir verwenden PyJWT, um JWTs zu validieren. Installiere es, falls du es noch nicht getan hast:
pip install pyjwt[crypto]
Füge zunächst diese gemeinsamen Hilfsfunktionen hinzu, um die JWT-Validierung zu handhaben:
import jwt
from jwt import PyJWKClient
from typing import Dict, Any
from auth_middleware import AuthInfo, AuthorizationError, JWKS_URI, ISSUER
jwks_client = PyJWKClient(JWKS_URI)
def validate_jwt(token: str) -> Dict[str, Any]:
"""JWT validieren und Payload zurückgeben"""
try:
signing_key = jwks_client.get_signing_key_from_jwt(token)
payload = jwt.decode(
token,
signing_key.key,
algorithms=['RS256'],
issuer=ISSUER,
options={'verify_aud': False} # Die Zielgruppe wird manuell überprüft
)
verify_payload(payload)
return payload
except jwt.InvalidTokenError as e:
raise AuthorizationError(f'Ungültiges Token: {str(e)}', 401)
except Exception as e:
raise AuthorizationError(f'Token-Validierung fehlgeschlagen: {str(e)}', 401)
def create_auth_info(payload: Dict[str, Any]) -> AuthInfo:
"""AuthInfo aus JWT-Payload erstellen"""
scopes = payload.get('scope', '').split(' ') if payload.get('scope') else []
audience = payload.get('aud', [])
if isinstance(audience, str):
audience = [audience]
return AuthInfo(
sub=payload.get('sub'),
client_id=payload.get('client_id'),
organization_id=payload.get('organization_id'),
scopes=scopes,
audience=audience
)
def verify_payload(payload: Dict[str, Any]) -> None:
"""Payload basierend auf Berechtigungsmodell überprüfen"""
# Implementiere hier deine Überprüfungslogik basierend auf dem Berechtigungsmodell
# Dies wird im Abschnitt zu den Berechtigungsmodellen unten gezeigt
pass
Implementiere anschließend die Middleware, um das Zugangstoken zu überprüfen:
from rest_framework.authentication import TokenAuthentication
from rest_framework import exceptions
from jwt_validator import validate_jwt, create_auth_info
class AccessTokenAuthentication(TokenAuthentication):
keyword = 'Bearer' # Verwende 'Bearer' statt 'Token'
def authenticate_credentials(self, key):
"""
Authentifiziere das Token, indem es als JWT validiert wird.
"""
try:
payload = validate_jwt(key)
auth_info = create_auth_info(payload)
# Erstelle ein benutzerähnliches Objekt, das Auth-Informationen für generische Nutzung hält
user = type('User', (), {
'auth': auth_info,
'is_authenticated': True,
'is_anonymous': False,
'is_active': True,
})()
return (user, key)
except AuthorizationError as e:
if e.status == 401:
raise exceptions.AuthenticationFailed(str(e))
else: # 403
raise exceptions.PermissionDenied(str(e))
Implementiere gemäß deinem Berechtigungsmodell die entsprechende Überprüfungslogik in jwt_validator.py
:
- Globale API-Ressourcen
- Organisation (nicht-API) Berechtigungen
- Organisationsbezogene API-Ressourcen
def verify_payload(payload: Dict[str, Any]) -> None:
"""Payload für globale API-Ressourcen überprüfen"""
# Überprüfe, ob der Audience-Claim mit deinem API-Ressourcenindikator übereinstimmt
audiences = payload.get('aud', [])
if isinstance(audiences, str):
audiences = [audiences]
if 'https://your-api-resource-indicator' not in audiences:
raise AuthorizationError('Ungültige Zielgruppe')
# Überprüfe erforderliche Berechtigungen für globale API-Ressourcen
required_scopes = ['api:read', 'api:write'] # Ersetze durch deine tatsächlich benötigten Berechtigungen
scopes = payload.get('scope', '').split(' ') if payload.get('scope') else []
if not all(scope in scopes for scope in required_scopes):
raise AuthorizationError('Unzureichende Berechtigung')
def verify_payload(payload: Dict[str, Any]) -> None:
"""Payload für Organisationsberechtigungen überprüfen"""
# Überprüfe, ob der Audience-Claim dem Organisationsformat entspricht
audiences = payload.get('aud', [])
if isinstance(audiences, str):
audiences = [audiences]
has_org_audience = any(aud.startswith('urn:logto:organization:') for aud in audiences)
if not has_org_audience:
raise AuthorizationError('Ungültige Zielgruppe für Organisationsberechtigungen')
# Überprüfe, ob die Organisations-ID mit dem Kontext übereinstimmt (ggf. aus dem Request-Kontext extrahieren)
expected_org_id = 'your-organization-id' # Aus dem Request-Kontext extrahieren
expected_aud = f'urn:logto:organization:{expected_org_id}'
if expected_aud not in audiences:
raise AuthorizationError('Organisations-ID stimmt nicht überein')
# Überprüfe erforderliche Organisationsberechtigungen
required_scopes = ['invite:users', 'manage:settings'] # Ersetze durch deine tatsächlich benötigten Berechtigungen
scopes = payload.get('scope', '').split(' ') if payload.get('scope') else []
if not all(scope in scopes for scope in required_scopes):
raise AuthorizationError('Unzureichende Organisationsberechtigung')
def verify_payload(payload: Dict[str, Any]) -> None:
"""Payload für organisationsbezogene API-Ressourcen überprüfen"""
# Überprüfe, ob der Audience-Claim mit deinem API-Ressourcenindikator übereinstimmt
audiences = payload.get('aud', [])
if isinstance(audiences, str):
audiences = [audiences]
if 'https://your-api-resource-indicator' not in audiences:
raise AuthorizationError('Ungültige Zielgruppe für organisationsbezogene API-Ressourcen')
# Überprüfe, ob die Organisations-ID mit dem Kontext übereinstimmt (ggf. aus dem Request-Kontext extrahieren)
expected_org_id = 'your-organization-id' # Aus dem Request-Kontext extrahieren
org_id = payload.get('organization_id')
if expected_org_id != org_id:
raise AuthorizationError('Organisations-ID stimmt nicht überein')
# Überprüfe erforderliche Berechtigungen für organisationsbezogene API-Ressourcen
required_scopes = ['api:read', 'api:write'] # Ersetze durch deine tatsächlich benötigten Berechtigungen
scopes = payload.get('scope', '').split(' ') if payload.get('scope') else []
if not all(scope in scopes for scope in required_scopes):
raise AuthorizationError('Unzureichende organisationsbezogene API-Berechtigungen')
Middleware auf deine API anwenden
Wende nun die Middleware auf deine geschützten API-Routen an.
from rest_framework.decorators import api_view, authentication_classes
from rest_framework.response import Response
from auth_middleware import AccessTokenAuthentication
@api_view(['GET'])
@authentication_classes([AccessTokenAuthentication])
def protected_view(request):
# Zugriff auf Authentifizierungsinformationen über request.user.auth
return Response({"auth": request.user.auth.to_dict()})
Oder mit klassenbasierten Views:
from rest_framework.views import APIView
from rest_framework.response import Response
from auth_middleware import AccessTokenAuthentication
class ProtectedView(APIView):
authentication_classes = [AccessTokenAuthentication]
def get(self, request):
# Zugriff auf Authentifizierungsinformationen über request.user.auth
return Response({"auth": request.user.auth.to_dict()})
from django.urls import path
from . import views
urlpatterns = [
path('api/protected/', views.protected_view, name='protected'),
# Oder für klassenbasierte Views:
# path('api/protected/', views.ProtectedView.as_view(), name='protected'),
]
Teste deine geschützte API
Zugangstokens erhalten
Von deiner Client-Anwendung: Wenn du eine Client-Integration eingerichtet hast, kann deine App Tokens automatisch erhalten. Extrahiere das Zugangstoken und verwende es in API-Anfragen.
Zum Testen mit curl / Postman:
-
Benutzertokens: Verwende die Entwicklertools deiner Client-App, um das Zugangstoken aus dem localStorage oder dem Netzwerk-Tab zu kopieren.
-
Maschine-zu-Maschine-Tokens: Verwende den Client-Credentials-Flow. Hier ein nicht-normatives Beispiel mit curl:
curl -X POST https://your-tenant.logto.app/oidc/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials" \
-d "client_id=your-m2m-client-id" \
-d "client_secret=your-m2m-client-secret" \
-d "resource=https://your-api-resource-indicator" \
-d "scope=api:read api:write"Möglicherweise musst du die Parameter
resource
undscope
entsprechend deiner API-Ressource und Berechtigungen anpassen; einorganization_id
-Parameter kann ebenfalls erforderlich sein, wenn deine API organisationsgebunden ist.
Möchtest du den Inhalt des Tokens inspizieren? Verwende unseren JWT Decoder, um deine JWTs zu dekodieren und zu überprüfen.
Geschützte Endpunkte testen
Gültige Token-Anfrage
curl -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..." \
http://localhost:3000/api/protected
Erwartete Antwort:
{
"auth": {
"sub": "user123",
"clientId": "app456",
"organizationId": "org789",
"scopes": ["api:read", "api:write"],
"audience": ["https://your-api-resource-indicator"]
}
}
Fehlendes Token
curl http://localhost:3000/api/protected
Erwartete Antwort (401):
{
"error": "Authorization header is missing"
}
Ungültiges Token
curl -H "Authorization: Bearer invalid-token" \
http://localhost:3000/api/protected
Erwartete Antwort (401):
{
"error": "Invalid token"
}
Berechtigungsmodell-spezifisches Testen
- Globale API-Ressourcen
- Organisations-(Nicht-API)-Berechtigungen
- Organisationsgebundene API-Ressourcen
Testszenarien für APIs, die mit globalen Berechtigungen geschützt sind:
- Gültige Berechtigungen: Teste mit Tokens, die deine erforderlichen API-Berechtigungen enthalten (z. B.
api:read
,api:write
) - Fehlende Berechtigungen: Erwarte 403 Verboten, wenn das Token die erforderlichen Berechtigungen nicht enthält
- Falsche Zielgruppe: Erwarte 403 Verboten, wenn die Zielgruppe nicht mit der API-Ressource übereinstimmt
# Token mit fehlenden Berechtigungen - erwarte 403
curl -H "Authorization: Bearer token-without-required-scopes" \
http://localhost:3000/api/protected
Testszenarien für organisationsspezifische Zugangskontrolle:
- Gültiges Organisationstoken: Teste mit Tokens, die den korrekten Organisationskontext enthalten (Organisations-ID und Berechtigungen)
- Fehlende Berechtigungen: Erwarte 403 Verboten, wenn der Benutzer keine Berechtigungen für die angeforderte Aktion hat
- Falsche Organisation: Erwarte 403 Verboten, wenn die Zielgruppe nicht mit dem Organisationskontext übereinstimmt (
urn:logto:organization:<organization_id>
)
# Token für falsche Organisation - erwarte 403
curl -H "Authorization: Bearer token-for-different-organization" \
http://localhost:3000/api/protected
Testszenarien, die API-Ressourcen-Validierung mit Organisationskontext kombinieren:
- Gültige Organisation + API-Berechtigungen: Teste mit Tokens, die sowohl den Organisationskontext als auch die erforderlichen API-Berechtigungen enthalten
- Fehlende API-Berechtigungen: Erwarte 403 Verboten, wenn das Organisationstoken die erforderlichen API-Berechtigungen nicht enthält
- Falsche Organisation: Erwarte 403 Verboten, wenn auf die API mit einem Token aus einer anderen Organisation zugegriffen wird
- Falsche Zielgruppe: Erwarte 403 Verboten, wenn die Zielgruppe nicht mit der organisationsgebundenen API-Ressource übereinstimmt
# Organisationstoken ohne API-Berechtigungen - erwarte 403
curl -H "Authorization: Bearer organization-token-without-api-scopes" \
http://localhost:3000/api/protected
Weiterführende Literatur
RBAC in der Praxis: Sichere Autorisierung für deine Anwendung implementieren
Entwicklung einer Multi-Tenant-SaaS-Anwendung: Ein vollständiger Leitfaden von Design bis Implementierung