CIBA (Backchannel-Authentifizierung)
Client Initiated Backchannel Authentication (CIBA) ist eine OpenID Connect-Erweiterung, die es einer Client-Anwendung ermöglicht, die Authentifizierung im Namen eines Benutzers zu initiieren, ohne dass der Benutzer direkt mit dem Client interagiert. Stattdessen empfängt der Benutzer eine Benachrichtigung (per SMS, E-Mail oder Push) auf einem separaten Gerät und genehmigt oder lehnt die Anfrage dort ab.
Häufige Anwendungsfälle:
- Ein Callcenter-Agent authentifiziert einen Kunden telefonisch, indem er eine Genehmigung auf dem Mobilgerät des Kunden auslöst
- Ein Zahlungsterminal fordert die Genehmigung des Kontoinhabers auf seinem Telefon an, bevor eine hochwertige Transaktion verarbeitet wird
- Eine Desktop-Anwendung delegiert den Login an das Telefon des Benutzers für ein passwortloses Erlebnis
- Ein Backend-Service initiiert Step-up-Authentifizierung, wenn eine sensible Operation angefordert wird
Funktionsweise
CIBA entkoppelt das Gerät, auf dem die Authentifizierung initiiert wird, von dem Gerät, auf dem der Benutzer seine Zustimmung gibt:
- Der Client sendet eine Backchannel-Authentifizierungsanfrage an
/api/oauth/cibamit einemlogin_hint(E-Mail, Telefonnummer oder Benutzer-ID), der den Benutzer identifiziert - Auris validiert die Anfrage und sendet eine Benachrichtigung an den Benutzer auf seinem registrierten Gerät oder Kanal
- Der Benutzer sieht die Anforderungsdetails (Anwendungsname, Binding-Nachricht) und genehmigt oder lehnt ab
- Der Client empfängt das Ergebnis über einen von drei Modi: Polling, Ping (Callback) oder Push
Benachrichtigungsmodi
Auris unterstützt drei Modi zur Übermittlung des Authentifizierungsergebnisses an den Client:
| Modus | Funktionsweise | Geeignet für |
|---|---|---|
| Poll | Client fragt den Token-Endpunkt in regelmäßigen Abständen ab, bis der Benutzer antwortet | Einfache Integrationen, serverseitige Clients |
| Ping | Auris sendet eine Benachrichtigung an eine vorregistrierte Callback-URL, dann tauscht der Client die Auth-Request-ID gegen ein Token | Ereignisgesteuerte Architekturen |
| Push | Auris liefert das Token direkt an eine vorregistrierte Callback-URL | Anforderungen mit geringer Latenz |
Poll-Modus ist am einfachsten zu implementieren und wird für die meisten Anwendungsfälle empfohlen. Ping- und Push-Modi erfordern eine öffentlich zugängliche Callback-URL und ordnungsgemäße Webhook-Sicherheit.
Console-Einrichtung
CIBA aktivieren
Gehe in der Auris Console zu Applications und wähle deine Anwendung. Aktiviere unter dem Tab Settings Enable CIBA.
Benachrichtigungsmodus konfigurieren
Wähle den Benachrichtigungsmodus (Poll, Ping oder Push). Gib für Ping- und Push-Modi eine Callback-URL an, an die Auris Benachrichtigungen sendet.
Benachrichtigungskanal festlegen
Wähle, wie Benutzer die Authentifizierungsanfrage-Benachrichtigung erhalten:
| Kanal | Anforderungen |
|---|---|
| Benutzer muss eine verifizierte E-Mail-Adresse haben | |
| SMS | Benutzer muss eine verifizierte Telefonnummer haben. Erfordert SMS-Provider-Konfiguration (Twilio). |
| Push | Erfordert eine benutzerdefinierte Push-Benachrichtigungs-Integration (erweitert) |
Anforderungslebensdauer konfigurieren
Lege die maximale Zeit fest, die eine CIBA-Authentifizierungsanfrage gültig bleibt, bevor sie abläuft:
| Einstellung | Standard | Hinweise |
|---|---|---|
| Anforderungslebensdauer | 300 Sekunden (5 Minuten) | Maximale Zeit, die der Benutzer hat, um zu genehmigen oder abzulehnen |
| Abfrage-Interval | 5 Sekunden | Minimales Interval für Poll-Modus-Clients |
Anmeldeinformationen kopieren
CIBA erfordert einen vertraulichen Client. Kopiere Client ID und Client Secret vom Tab Credentials.
Implementierung
JavaScript (Poll-Modus)
const AURIS_DOMAIN = 'https://auth.yourdomain.com'
const CLIENT_ID = 'your-client-id'
const CLIENT_SECRET = 'your-client-secret'
// Schritt 1: Backchannel-Authentifizierung initiieren
const cibaResponse = await fetch(`${AURIS_DOMAIN}/api/oauth/ciba`, {
method: 'POST',
headers: {
'Content-Type': 'application/x-www-form-urlencoded',
'Authorization': `Basic ${btoa(`${CLIENT_ID}:${CLIENT_SECRET}`)}`,
},
body: new URLSearchParams({
scope: 'openid profile',
login_hint: '[email protected]',
binding_message: 'Anmeldung beim Dashboard genehmigen',
}),
}).then(r => r.json())
console.log('Auth-Request-ID:', cibaResponse.auth_req_id)
console.log('Benutzer erhält eine Benachrichtigung...')
// Schritt 2: Auf Token warten
const token = await pollForCibaToken(cibaResponse)
async function pollForCibaToken(cibaResponse) {
const interval = cibaResponse.interval * 1000
const expiresAt = Date.now() + cibaResponse.expires_in * 1000
while (Date.now() < expiresAt) {
await new Promise(resolve => setTimeout(resolve, interval))
const response = await fetch(`${AURIS_DOMAIN}/api/auth/token`, {
method: 'POST',
headers: {
'Content-Type': 'application/x-www-form-urlencoded',
'Authorization': `Basic ${btoa(`${CLIENT_ID}:${CLIENT_SECRET}`)}`,
},
body: new URLSearchParams({
grant_type: 'urn:openid:params:grant-type:ciba',
auth_req_id: cibaResponse.auth_req_id,
}),
})
if (response.ok) {
return await response.json()
}
const error = await response.json()
if (error.error === 'authorization_pending') continue
if (error.error === 'slow_down') {
await new Promise(r => setTimeout(r, 5000))
continue
}
if (error.error === 'expired_token') {
throw new Error('CIBA-Anfrage abgelaufen. Benutzer hat nicht rechtzeitig geantwortet.')
}
if (error.error === 'access_denied') {
throw new Error('Benutzer hat die Authentifizierungsanfrage abgelehnt.')
}
throw new Error(`CIBA-Fehler: ${error.error}`)
}
throw new Error('CIBA-Anfrage abgelaufen.')
}CIBA-Anfrageparameter
Die Backchannel-Authentifizierungsanfrage akzeptiert folgende Parameter:
| Parameter | Erforderlich | Beschreibung |
|---|---|---|
scope | Ja | OpenID Connect-Scopes (muss openid enthalten) |
login_hint | Ja | Identifiziert den Benutzer. Kann eine E-Mail-Adresse, Telefonnummer oder Benutzer-ID sein. |
binding_message | Nein | Kurze Nachricht, die dem Benutzer auf dem Genehmigungsbildschirm angezeigt wird (z. B. “Anmeldung beim Dashboard genehmigen”). Max. 128 Zeichen. |
requested_expiry | Nein | Angeforderte Lebensdauer der Authentifizierungsanfrage in Sekunden. Begrenzt durch die Anwendungskonfiguration. |
acr_values | Nein | Angeforderte Authentication Context Class Reference-Werte für Step-up-Auth |
Die Binding-Nachricht
Die binding_message ist ein kritisches Sicherheitsmerkmal. Sie wird dem Benutzer in der Genehmigungsbenachrichtigung angezeigt und sollte genug Kontext enthalten, damit der Benutzer bestätigen kann, was er genehmigt:
- “Anmeldung beim Dashboard genehmigen” (Login)
- “Zahlung von EUR 49,99 an ACME Corp bestätigen” (Zahlungsgenehmigung)
- “Support-Agent Zugriff auf dein Konto autorisieren” (Callcenter)
Füge immer eine aussagekräftige Binding-Nachricht ein. Ohne sie können Benutzer eine legitime CIBA-Anfrage nicht von einem Phishing-Versuch unterscheiden. Die Binding-Nachricht sollte spezifisch für die aktuelle Aktion sein — verwende nie eine generische “Anmeldung genehmigen”-Nachricht für Zahlungs- oder sensible Operationen.
Fehlerbehandlung
| Fehlercode | HTTP-Status | Bedeutung |
|---|---|---|
authorization_pending | 400 | Benutzer hat noch nicht auf die Benachrichtigung reagiert |
slow_down | 400 | Client fragt zu schnell ab |
expired_token | 400 | Authentifizierungsanfrage abgelaufen (Benutzer hat nicht reagiert) |
access_denied | 400 | Benutzer hat die Anfrage explizit abgelehnt |
invalid_request | 400 | Fehlende oder ungültige Parameter |
unknown_user_id | 400 | Der login_hint passt zu keinem bekannten Benutzer |
unauthorized_client | 401 | Client ist nicht für CIBA autorisiert |
Sicherheitsüberlegungen
- Vertraulicher Client erforderlich: CIBA erfordert immer Client-Authentifizierung (Client ID + Secret). Öffentliche Clients können CIBA nicht verwenden.
- Kurze Anforderungslebensdauer: Standard 300 Sekunden. Kürzere Lebensdauern reduzieren das Fenster für Social-Engineering-Angriffe.
- Benutzereinwilligung erforderlich: Der Benutzer muss die Anfrage explizit genehmigen. Auris genehmigt nie automatisch.
- Binding-Nachricht-Anzeige: Die Genehmigungs-Oberfläche zeigt immer die Binding-Nachricht, den Anwendungsnamen und angeforderte Scopes.
- Benachrichtigungskanal-Verifizierung: Auris sendet CIBA-Benachrichtigungen nur an verifizierte E-Mail-Adressen oder Telefonnummern.
- Audit-Protokollierung: Alle CIBA-Anfragen (initiiert, genehmigt, abgelehnt, abgelaufen) werden für Audit-Zwecke protokolliert.
API-Endpunkte
/api/oauth/cibaInitiiert eine Backchannel-Authentifizierungsanfrage. Erfordert Client-Authentifizierung (Basic Auth oder client_id/client_secret im Body). Gibt auth_req_id, expires_in und interval zurück.
/api/auth/tokenToken-Endpunkt. Für CIBA grant_type=urn:openid:params:grant-type:ciba und auth_req_id setzen. Gibt Access Token bei Benutzer-Genehmigung oder Abfrage-Fehlercode zurück.
/api/oauth/ciba/requestsRequires: view:ciba_requestsListet aktive CIBA-Authentifizierungsanfragen für den Tenant auf. Admin-Endpunkt für Monitoring.
Erforderliche Berechtigungen
| Operation | Berechtigung |
|---|---|
| CIBA auf einer Anwendung aktivieren | manage:applications |
| CIBA-Einstellungen konfigurieren | manage:ciba_config |
| Aktive CIBA-Anfragen auflisten | view:ciba_requests |
| Token initiieren/abfragen | Nur Client-Authentifizierung (keine Benutzerberechtigung) |
Verwandte Anleitungen
- Device Authorization Flow — Ähnlicher entkoppelter Flow für eingabebeschränkte Geräte
- Hosted Login (PKCE) — Standard-browserbasierte Authentifizierung
- Multi-Faktor-Authentifizierung — CIBA kann für Step-up-Auth mit MFA integriert werden