Erweitertes OAuth2

Auris unterstützt vier erweiterte OAuth2-Funktionen über den standardmäßigen Authorization Code + PKCE-Flow hinaus: Device Authorization Flow, Client-Initiated Backchannel Authentication (CIBA), DPoP (Demonstration of Proof-of-Possession) und Token Exchange. Jede Funktion wird pro Anwendung konfiguriert und kann unabhängig aktiviert werden.

Diese Funktionen adressieren Enterprise-Szenarien wie die Authentifizierung auf eingabebeschränkten Geräten (Smart-TVs, CLI-Tools), serverinitierte Authentifizierung (Call-Center, Kiosk-Genehmigungen), kryptografische Senderbindung von Token und kontrollierte Identitätsdelegation.

Zugriff über Konsole → Anwendungen → Anwendung auswählen → Einstellungen-Tab.

Device Authorization Flow (RFC 8628)

Der Device Authorization Flow ermöglicht Benutzern die Authentifizierung auf Geräten ohne Browser oder mit eingeschränkten Eingabemöglichkeiten. Das Gerät zeigt einen Kurzcode an, den der Benutzer auf einem separaten Gerät (Telefon oder Computer) eingibt, um die Sitzung zu autorisieren.

Device Flow aktivieren

Verifizierungs-URI

Nach dem Aktivieren des Device Flows stellt Auris eine Verifizierungs-URI für deine Anwendung bereit. Dies ist die URL, die du Benutzern zusammen mit dem Gerätecode anzeigst. Das Format ist:

https://auth.ihredomain.de/hosted/device

Deine Geräteanwendung sollte sowohl die Verifizierungs-URI als auch den Benutzercode anzeigen, zum Beispiel:

Um dich anzumelden, besuche: https://auth.ihredomain.de/hosted/device
Code eingeben: ABCD-EFGH

So funktioniert es

1. Das Gerät fordert einen Gerätecode von POST /api/oauth/device/authorize an
2. Der Benutzer besucht die Verifizierungs-URI und gibt den Code ein
3. Der Benutzer authentifiziert sich normal (Passwort, MFA, SSO — was auch immer dein Tenant erfordert)
4. Das Gerät fragt POST /api/auth/token mit grant_type=urn:ietf:params:oauth:grant-type:device_code ab, bis der Benutzer die Authentifizierung abschließt
5. Nach der Autorisierung empfängt das Gerät Zugriffs- und Refresh-Token

Client-Initiated Backchannel Authentication (CIBA)

CIBA ermöglicht Server-zu-Server-Authentifizierung, bei der die vertrauende Partei die Authentifizierung initiiert, ohne dass der Benutzer an der Anwendung anwesend ist. Der Benutzer erhält eine Benachrichtigung (SMS oder E-Mail) und genehmigt die Anmeldung auf seinem eigenen Gerät.

Typische Anwendungsfälle sind Call-Center-Authentifizierung (“Wir haben eine Benachrichtigung an Ihr Telefon gesendet — bitte genehmigen Sie sie, um Ihre Identität zu verifizieren”) und Hintergrund-ReAuthentifizierung für lang laufende Sitzungen.

CIBA aktivieren

Benachrichtigungsmodi

DPoP (Demonstration of Proof-of-Possession) — RFC 9449

DPoP bindet Zugriffs-Token an einen bestimmten Client, indem der Client auf jede Anfrage hin den Besitz eines privaten Schlüssels nachweisen muss. Dies verhindert Token-Diebstahl und Replay-Angriffe — selbst wenn ein Zugriffs-Token abgefangen wird, kann es ohne den entsprechenden privaten Schlüssel nicht verwendet werden.

DPoP aktivieren

So funktioniert DPoP

1. Der Client generiert ein asymmetrisches Schlüsselpaar (typischerweise ECDSA P-256)
2. Bei jeder Token-Anforderung erstellt der Client einen mit seinem privaten Schlüssel signierten DPoP-Nachweis-JWT, der die HTTP-Methode, URL und einen eindeutigen Bezeichner enthält
3. Auris verifiziert den Nachweis und bindet das ausgestellte Token an den öffentlichen Schlüssel des Clients (JWK-Thumbprint)
4. Bei nachfolgenden API-Aufrufen fügt der Client sowohl das Zugriffs-Token als auch einen frischen DPoP-Nachweis-Header ein
5. Ressourcenserver verifizieren, dass der jkt-Claim (JWK Thumbprint) des Tokens mit dem DPoP-Nachweis übereinstimmt

Token Exchange (RFC 8693)

Token Exchange ermöglicht es einem Dienst, ein Zugriffs-Token gegen ein neues Token mit anderen Scopes, Subjekt oder Audience zu tauschen. Dies unterstützt zwei Muster: Impersonation (als ein anderer Benutzer handeln) und Delegation (im Namen eines anderen Benutzers handeln, während die ursprüngliche Identität beibehalten wird).

Token Exchange aktivieren

Monitoring

Die Konsole bietet dedizierte Monitoring-Seiten für jede erweiterte OAuth2-Funktion. Zugriff über den Abschnitt Erweitertes OAuth in der Seitenleiste.

Gerätecodes

Gehe zu Konsole → Erweitertes OAuth → Gerätecodes, um alle aktiven und abgelaufenen Geräteautorisierungssitzungen anzuzeigen.

CIBA-Anforderungen

Gehe zu Konsole → Erweitertes OAuth → CIBA-Anforderungen, um Backchannel-Authentifizierungsanforderungen anzuzeigen.

Token-Austausche

Gehe zu Konsole → Erweitertes OAuth → Token-Austausche, um das Audit-Protokoll aller Token-Austauschoperationen anzuzeigen.

Risikobewertung

Erweiterte OAuth2-Funktionen integrieren sich mit der Auris-Risikobewertungs-Engine. Wenn Risikobewertung aktiviert ist, wird jede Authentifizierung über Device Flow, CIBA oder Token Exchange genauso auf Risiko bewertet wie eine Standardanmeldung. Hochrisiko-Authentifizierungen können Step-Up-MFA-Anforderungen auslösen.

Für die detaillierte Konfiguration der Risiko-Engine, Faktorgewichtungen, Schwellenwerte und benutzerdefinierte Regeln, siehe die dedizierte Seite Risikobewertung & Adaptives MFA.

Berechtigungen

Die folgenden Berechtigungen steuern den Zugriff auf erweiterte OAuth2-Funktionen:

Zugehörige Anleitungen

• Risikobewertung & Adaptives MFA — Die Risiko-Engine konfigurieren, die alle OAuth2-Flows schützt
• Device Authorization Flow — Entwickleranleitung zur Implementierung des Device Flows in deiner Anwendung
• CIBA-Integration — Entwickleranleitung für Backchannel-Authentifizierung
• DPoP für Token-Sicherheit — Wie DPoP in deiner Client-Anwendung implementiert wird
• Token Exchange — Entwickleranleitung für Impersonation und Delegation
• Anwendungen — Anwendungseinstellungen in der Konsole verwalten