CIBA ist ein Entkopplungsfluss, der die Client-Anwendung (auch als vertrauende Partei bezeichnet) vom Authentifizierungsserver entkoppelt.
Wir stoßen ständig auf Authentifizierungsabläufe über den Frontend-Kanal, wie beispielsweise OAuth 2.0 und SAML . Ein Beispiel: Wenn Sie sich bei YouTube anmelden, wird beim Klicken auf „Anmelden“ die Anfrage per Browser-Weiterleitung über den Frontend-Kanal an „accounts.google.com“ gesendet. Dort können Sie sich authentifizieren und YouTube Zugriff gewähren. Dies ist ein Beispiel für einen Redirect Flow.
Umleitungsflüsse eignen sich gut für Szenarien, in denen sich die Clientanwendung und der Authentifizierungsserver auf demselben Gerät befinden.
Nun stellt sich die Frage: Gibt es Szenarien, in denen das Gerät, auf dem die Clientanwendung ausgeführt wird, und das Gerät, auf dem die Benutzerauthentifizierung erfolgt, zwei verschiedene Geräte sein müssen?
WAS IST CIBA?
CIBA (Client Initiated Backchannel Authentication) ist eine Erweiterung des herkömmlichen OpenID Connect-Ablaufs. Bei CIBA findet eine direkte Kommunikation zwischen der vertrauenden Partei (Client-Anwendung) und dem OpenID-Anbieter statt, ohne Umleitungen über den Browser des Benutzers.
Einfach ausgedrückt: Die Client-Anwendung und der Authentifizierungsserver befinden sich auf zwei separaten Geräten – entkoppelt. CIBA ist ein Entkopplungsfluss, der die Client-Anwendung und den Authentifizierungsserver entkoppelt. Der Authentifizierungsserver und die Client-Anwendung kommunizieren über den Backchannel (Server-zu-Server-Kommunikation).
Bei CIBA ist im Gegensatz zu anderen Umleitungsflüssen keine Benutzerinteraktion am Verbrauchsgerät erforderlich. CIBA kann den Authentifizierungsfluss für den angegebenen Benutzer selbst initiieren. Daher benötigen wir zur Authentifizierung nicht mehrere Browserumleitungen wie im Fall des Autorisierungscodeflusses und des impliziten Flusses.
WARUM BRAUCHEN WIR CIBA?
Lassen Sie uns dies anhand eines Beispiels verstehen –
Nehmen wir an, Sie bestellen ein Uber. Das Taxi kommt und bringt Sie zu Ihrem Ziel. Wie gewohnt klicken Sie auf den Button „Mit UPI bezahlen“. Die App erkennt die UPI-Anwendung auf Ihrem Gerät und leitet Sie zu dieser weiter, beispielsweise zu Google Pay. Sie authentifizieren sich mit Ihrer UPI-PIN und klicken auf „Bezahlen“. Ihr Kontostand ist jedoch niedrig. Deshalb bitten Sie einen Freund, die Rechnung zu bezahlen. Das Problem hierbei ist, dass wir einen Redirect-Flow verwenden : Sobald Sie auf „Bezahlen“ klicken, leitet die Uber-App Sie zu Ihrer Banking-App weiter. Wie erreichen Sie nun, dass die Weiterleitung zur App Ihres Freundes erfolgt? Die Client-Anwendung (Uber-App) und die Authentifizierungsserver-App (Google Pay Ihres Freundes) müssen sich auf demselben Gerät befinden.
Betrachten wir nun dasselbe Szenario, jedoch mit entkoppeltem Datenfluss –
Nehmen wir an, Sie werden zum Zeitpunkt der Zahlung aufgefordert, die UPI-ID einzugeben. Anstatt zur Zahlungs-App weitergeleitet zu werden, wird der Inhaber der UPI-ID benachrichtigt, die Zahlung an die Client-Anwendung Uber entweder vorzunehmen oder abzulehnen. Mit anderen Worten, es erfolgt keine Weiterleitung. In diesem Ablauf können Sie die UPI Ihres Freundes eingeben und dieser erhält eine Benachrichtigung wie die im folgenden Bild gezeigte. Somit kann er die Zahlung mit seinem Gerät vornehmen. Sobald die Zahlung erfolgt ist, wird die Client-Anwendung Uber benachrichtigt. Voilà!
Angesichts des oben beschriebenen Szenarios besteht tatsächlich die Notwendigkeit eines entkoppelten Datenflusses.
CIBA WORKFLOW
Um den Arbeitsablauf von CIBA richtig zu verstehen, schauen wir uns zunächst dieses vereinfachte CIBA-Flussbild an.
Komponenten im Ablauf –
- Client-Anwendung – Eine Drittanbieteranwendung, die einen Dienst bereitstellt, beispielsweise Uber.
- Authentifizierungsserver – Der Server, auf dem die Endbenutzerauthentifizierung und die Zustimmungsbestätigung durchgeführt werden, beispielsweise Mobiltelefon.
- Autorisierungsserver – Der Server, der die OAuth-Client-Token an die Client-Anwendung ausgibt, beispielsweise der Google Pay-Autorisierungsserver.
- Mitglied – Der Ressourcenbesitzer, dessen Interaktion auf dem Authentifizierungsserver erforderlich ist, z. B. Zahler
DEN FLOW VERSTEHEN
1. Ablaufinitiierung – Die Client-Anwendung und der Bankautorisierungsserver kommunizieren über den Backchannel. Dazu sendet die Client-Anwendung eine HTTP-POST-Anfrage an den Bankautorisierungsserver.
2. Authentifizierung und Zustimmungsbestätigung des Endbenutzers – Nach Empfang der HTTP-Anfrage delegiert der Autorisierungsserver die Aufgabe der Authentifizierung und Zustimmungsbestätigung des Endbenutzers an das Authentifizierungsgerät.
3. Token-Ausgabe – Im CIBA-Ablauf benötigen wir keine HTTP-Browser-Weiterleitungen, um Token an die Client-Anwendung auszugeben, da der Autorisierungsserver und die Client-Anwendung direkt über den Backchannel kommunizieren können.
In CIBA gibt es nach der Zustimmungsbestätigung drei Abläufe: den POLL-Modus , den PING-Modus und den PUSH-Modus . In jedem Ablauf werden ein ID-Token, ein Zugriffstoken und optional ein Aktualisierungstoken ausgestellt.
- POLL-Modus – Im POLL-Modus, nachdem eine Antwort vom Backchannel-Authentifizierungsendpunkt erhalten wurde, Der Client wiederholt Token-Anfragen (Polling) an den Token-Endpunkt. Wenn der Prozess auf dem Authentifizierungsgerät noch nicht abgeschlossen ist, gibt der Token-Endpunkt „400 Bad request“ mit JSON zurück, das „error“:“ authorization_pending“ enthält. Daher wiederholt der Client Token-Anfragen, bis er die Token erhält oder ein Timeout-Fehler auftritt.
- PING-Modus – Im PING-Modus sendet der Autorisierungsserver eine Benachrichtigung an den Clientbenachrichtigungsendpunkt nachdem der Vorgang auf dem Authentifizierungsserver abgeschlossen ist. Danach stellt die Client-Anwendung eine Token-Anforderung an den Autorisierungsserver.
- PUSH-Modus – Im Push-Modus, wenn die Verarbeitung auf dem Authentifizierungsserver abgeschlossen ist, Autorisierungsserver generiert das ID-Token, das Access-Tokenund refresh_token (optional) und liefert es direkt an den Clientbenachrichtigungsendpunkt. Daher muss die Clientanwendung keine Tokenanforderung stellen.
CIBA-ANWENDUNGSFÄLLE
- Wenn der Benutzer der vertrauenden Partei (Client-Anwendung) nicht vertrauen kann und deshalb keine Sitzung in seinem Browser erstellen kann, um eine Autorisierung zu erteilen. Beispiel: das Verkaufsterminal im Einkaufszentrum. Um im Einkaufszentrum zu bezahlen, möchten Sie beispielsweise Ihre Banksitzung nicht auf dem Gerät des Benutzers erstellen. Sie möchten lieber ein OTP erhalten und die Transaktion von Ihrem eigenen Gerät aus autorisieren, weil Sie der Client-Anwendung nicht vertrauen.
- Wenn der Benutzer keinen Zugriff auf die vertrauende Partei hat. Z. B. die Fälle, die dem Beispiel oben ähneln. Wenn Ihr Freund keinen Zugriff auf Ihre Uber-App hat und die Transaktion trotzdem autorisieren möchte.
- Wenn die vertrauende Partei keinen Browser hat, z. B. IoT. Wenn Sie die Mikrowelle (vertrauende Partei) von Ihrem Gerät aus einschalten möchten.
FAZIT
Zusammenfassend lässt sich sagen, dass allen oben genannten Anwendungsfällen gemeinsam ist, dass wir auf unseren Mobilgeräten stark authentifizierte Sitzungen verwenden.
Die einzige Einschränkung besteht darin, dass wir diese Sitzungen nicht in der vertrauenden Partei haben können.
Was wäre, wenn wir ein anderes Gerät autorisieren möchten? Dann müssen wir auf diesem Gerät eine Authentifizierungssitzung erstellen. Aber was wäre, wenn wir das alles einfach umgehen könnten? Insbesondere bei Bankanwendungen.
Hinterlasse einen Kommentar