CIBA ist ein Entkopplungsfluss, der die Client-Anwendung (auch als vertrauende Partei bezeichnet) vom Authentifizierungsserver entkoppelt.
Wir stoßen ständig auf Front-Channel-Authentifizierungsflüsse, wie OAuth 2.0, SAML Flows. Zum Beispiel, wenn Sie versuchen, sich bei YouTube anzumelden. Wenn Sie auf die Schaltfläche „Anmelden“ klicken, wird die Anfrage per Browser-Umleitung über den Frontkanal an „accounts.google.com“ gesendet. Dort können Sie sich authentifizieren und YouTube Zugriff gewähren. Dies ist ein Beispiel für einen Umleitungsflow.
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 traditionellen OpenID Connect-Ablaufs. In CIBA gibt es eine direkte Kommunikation zwischen Relying Party (Client-Anwendung) und OpenID-Provider 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 –
Sie buchen beispielsweise ein Uber-Taxi. Das Taxi kommt und bringt Sie zu Ihrem Ziel. Wie üblich klicken Sie auf die Schaltfläche „Mit UPI bezahlen“. Es erkennt die UPI-Anwendung auf Ihrem Gerät und leitet Sie zu dieser Anwendung weiter, beispielsweise Google Pay. Sie authentifizieren sich, indem Sie die UPI-PIN eingeben und auf „Bezahlen“ klicken. Ihr Kontostand ist jedoch niedrig. Daher rufen Sie Ihren Freund an und bitten ihn, zu bezahlen. Aber hier ist das Problem, dass wir ein Fluss umleiten Das heißt, sobald Sie auf die Schaltfläche „Bezahlen“ klicken, leitet die Uber-App Sie zu Ihrer Banking-App weiter. Wie können Sie nun dafür sorgen, dass Sie zur App Ihres Freundes weitergeleitet werden? Die Client-Anwendung (Uber-App) und die Authentifizierungsserver-App (Google Pay Ihres Freundes) müssen sich auf demselben Gerät befinden.
Betrachten wir nun das gleiche Szenario, aber mit dem entkoppelter Durchfluss -
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à!
In Anbetracht des oben beschriebenen Szenarios, Es besteht tatsächlich die Notwendigkeit, einen entkoppelten Fluss zu haben.
CIBA WORKFLOW
Um den Arbeitsablauf von CIBA richtig zu verstehen, schauen wir uns zunächst dieses vereinfachte CIBA-Flussbild an.
Komponenten im Fluss -
- 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. Flow-Initiierung – Die Client-Anwendung und der Banking-Autorisierungsserver kommunizieren über den Backchannel. Daher sendet die Client-Anwendung eine HTTP-POST-Anforderung an den Banking-Autorisierungsserver.
2. Endbenutzerauthentifizierung und Zustimmungsbestätigung – Nach Erhalt der HTTP-Anforderung delegiert der Autorisierungsserver die Aufgabe der Endbenutzerauthentifizierung und Zustimmungsbestätigung an das Authentifizierungsgerät.
3. Ausgabe von Token – Im CIBA-Flow benötigen wir keine HTTP-Browserumleitungen, 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. Sie heißen POLL-Modus, PING-Modusund PUSH-ModusIn jedem Flow werden ein ID-Token, ein Zugriffstoken und optional ein Aktualisierungstoken ausgegeben.
- 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 für alle oben genannten Anwendungsfälle Folgendes gilt: stark authentifizierte Sitzungs auf unseren Mobilgeräten.
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