Ablauf der Authentifizierung für Nutzer

Überblick

Der Zweck des Authentifizierungsvorgangs besteht darin, den Nutzer beim Zahlungsintegrator (Integrator) zu identifizieren und zu authentifizieren.

Die Authentifizierung ist eine Eingabe für andere Methoden. Dies gilt insbesondere für associateAccount und capture. Das bedeutet, dass der Authentifizierungsnachweis als Eingabe (Parameter) für diese beiden Methoden verwendet wird.

Google kann den Authentifizierungsvorgang auch im eigenständigen Modus verwenden, um einen Nutzer zu bestätigen. In diesem Fall wird sie nicht als Eingabe für einen anderen Ablauf verwendet, sondern nur zur Überprüfung, ob ein Nutzer diese Identität authentifizieren kann.

Beachten Sie, dass Google während des Onboardings gemeinsam mit Ihnen den Authentifizierungsmechanismus auswählt, der am besten zu Ihrem Produkt passt.

Ablauf

Es gibt zwei Möglichkeiten zur Authentifizierung eines Nutzers mit jeweils einem eigenen Ablauf. Zum Zeitpunkt der Integration muss der Integrator entscheiden, welche verwendet werden soll.

1. Authentifizierung weiterleiten
2. OTP-Authentifizierung per SMS-MT

Authentifizierung weiterleiten

Ein Google-Nutzer, der eine Authentifizierung benötigt, kann zur App des Integrators oder seiner Website weitergeleitet werden, um seine Identität bestätigen zu lassen. Hier ein kurzer Überblick über die Schritte in diesem Ablauf:

1. Google leitet den Nutzer zur Web- oder Android-App des Integrators weiter, wo er authentifiziert werden kann.
2. Zur Authentifizierung wird die Authentifizierungs-requestId (von AuthenticationRequest) als Authentifizierungsnachweis verwendet.
3. Dies führt zu einer signierten Antwort, die als AuthenticationResponse bezeichnet wird.
4. Anschließend leitet die App oder Website den Nutzer zurück zu Google.

Hinweis :Im eigenständigen Modus bestimmen die signierte Antwort (Schritt 3) und der gspResult, ob die Authentifizierung erfolgreich war.

Für die Weiterleitungsauthentifizierung wird eine HTTP-GET-Methode verwendet, bei der die Parameter in der URL einer Webanwendung codiert sind. Dabei wird ein Android-Intent zur Authentifizierung einer Android-Anwendung verwendet. Weitere Informationen zur Codierung finden Sie unter Webauthentifizierung. Informationen zu Android-Intent-Parametern finden Sie unter Android-Authentifizierung.

Das Ergebnis jedes dieser Authentifizierungsmechanismen ist eine signierte Antwort, die als AuthenticationResponse bezeichnet wird. Dieser Intent sollte die verschlüsselte, codierte Google-Standardantwort für die Zahlungsauthentifizierung (gspAuthenticationResponse) enthalten, um über eine erfolgreiche Authentifizierung zu informieren. Im eigenständigen Modus werden gspResult und die Signatur verwendet, um die erfolgreiche Authentifizierung zu ermitteln.

Hinweis :Der Integrator muss sowohl eine für Mobilgeräte optimierte Webversion als auch eine für Computer optimierte Version seiner Web-App bereitstellen.

Das folgende Sequenzdiagramm zeigt die Interaktion zwischen dem Browser des Nutzers, Google und der Webanwendung des Integrators:

Weiterleitungs-Web-Authentifizierungsablauf

Im Folgenden finden Sie eine Liste der Objekte und ihrer Bedeutung:

• Nutzer: Die Person, die ihrem Google-Konto eine Zahlungsmethode hinzufügen möchte.
• Google-UI: In diesem Fall die Weboberfläche von Google, auf der der Kunde mit der Einrichtung einer Zahlungsmethode beginnt.
• Google-Server: Der Back-End-Server bei Google, der die Authentifizierungsprüfung und andere Authentifizierungsaufgaben durchführt.
• Payment Integrator Web: Die Website des Integrators, bei der der Nutzer ein Konto hat.

Bei diesem Authentifizierungsvorgang gehen wir bereits davon aus, dass sich der Nutzer auf der Google-Website (Google UI) befindet und versucht, eine Zahlungsmethode hinzuzufügen. Hier fängt alles an.

1. In der Google-Benutzeroberfläche wird eine Authentifizierungs-URL erstellt, die an den Google-Server (Back-End) gesendet wird. Dadurch wird der Authentifizierungsprozess ausgelöst.
2. Der Google-Server erstellt eine Authentifizierungsanfrage (AuthenticationRequest).
3. Die Authentifizierungsanfrage, die an die Google-Benutzeroberfläche gesendet wurde.
4. Der Nutzer wird aufgefordert, seine ID beim Integrator zu authentifizieren.
5. Der Nutzer antwortet, dass er sich authentifizieren möchte, und sendet diese Nachricht an die Website des Integrators.
6. Die Website des Zahlungsintegrators fordert eine Bestätigung der Identität des Nutzers an.
7. Der Nutzer legt einen Identitätsnachweis vor, der auf die Website des Zahlungsintegrators gesendet wird.
8. Der Integrator erstellt eine Antwort (authenticationResponse) auf den Nachweis, den er erhalten hat, wobei das authenticationResponse in der Nachricht codiert ist.
9. Diese Antwort-URL wird an den Nutzer gesendet.
10. Die Antwort-URL wird sofort vom Nutzer an die Google-Benutzeroberfläche gesendet.
11. Die Google-UI sendet die Antwort an den Google-Server.
12. Der Google-Server interpretiert die Antwort als verifiziert.

Das nächste Sequenzdiagramm zeigt die Interaktion zwischen dem Telefon des Nutzers, Google und der Android-Anwendung des Integrators:

Authentifizierungsablauf zur Weiterleitung der Android-App

Hinweis: Keines der beiden obigen Diagramme illustriert die Verwendung der authenticationId als Eingabe für einen anderen Ablauf. Meistens wird sie aber verwendet.

Dies sind die Objekte und was sie repräsentieren:

• Nutzer: Die Person, die ihrem Google-Konto eine Zahlungsmethode hinzufügen möchte.
• Google UI: In diesem Fall die Benutzeroberfläche der App, auf der der Kunde mit der Einrichtung einer Zahlungsmethode beginnt.
• Google-Server: Der Back-End-Server bei Google, der die Authentifizierungsprüfung und andere Authentifizierungsaufgaben durchführt.
• Payment Integrator APK: Integrator-App, über die der Nutzer Zugriff auf sein Integratorkonto hat
• Zahlungsintegrator-Server: Der Back-End-Server des Integrators, auf dem die Informationen des Nutzers gespeichert sind.

Da es sich um einen Authentifizierungsvorgang handelt, gehen wir bereits davon aus, dass der Nutzer eine App (Google-UI) verwendet und versucht, eine Zahlungsmethode hinzuzufügen. Hier beginnt die Initialisierung.

1. Die Google-Benutzeroberfläche erstellt einen Authentifizierungsaufruf, der an den Google-Server (Back-End) gesendet wird.
2. Eine Authentifizierungsanfrage (AuthenticationRequest) wird vom Google-Server erstellt.
3. Der Google-Server sendet ein Aufruf-APK an die Google-Benutzeroberfläche (App) und fordert eine Authentifizierung an.
4. Die Nutzerinformationen werden von der Google-Benutzeroberfläche an das Zahlungsintegrator-APK (AUTHENTICATE_V1(authReq)) gesendet.
5. Das Zahlungsintegrator-APK sendet die Anfrage (authReq) an den Server des Zahlungsintegrators.
6. Der Zahlungsintegrator-Server sendet eine Aufforderung an das Zahlungsintegrator-APK zurück.
7. Das Zahlungsintegrator-APK sendet die Aufforderung an den Nutzer zurück.
8. Der Nutzer legt einen Identitätsnachweis vor, der an das Zahlungsintegrator-APK gesendet wird.
9. Dieser Nachweis wird an den Zahlungsintegrator-Server gesendet.
10. Der Server erstellt ein signiertes authenticationResponse.
11. Die Authentifizierungsantwort war erfolgreich und die Nachricht authResp wird an das Zahlungsintegrator-APK gesendet.
12. Die Erfolgsmeldung (authResp) wird vom Payment Integrator APK an die Google-Benutzeroberfläche gesendet.
13. Die Google-Benutzeroberfläche sendet die Antwort an den Google-Server.
14. Der Google-Server interpretiert die erfolgreiche Antwort.

SMS-MT-OTP-Authentifizierung

Eine weitere Authentifizierungsmethode ist der SMS-MT-OTP (Short Message Service, mobil beendet), Einmalpasswort. Bei diesem Mechanismus wird die Telefonnummer des Nutzers verwendet, um ihm ein Einmalpasswort zur Authentifizierung zu senden. Google bittet den Integrator, ein OTP an die Telefonnummer des Nutzers zu senden. Wenn ein Nutzer das OTP erhält und dieses dann in der Google-Oberfläche eingibt, wird der Nutzer bestätigt.

Dazu gehören die folgenden Schritte:

1. Die Benutzeroberfläche (UI) von Google fordert den Nutzer auf, die Telefonnummer einzugeben, die bereits beim Integrator registriert ist.
2. Der Nutzer gibt eine Telefonnummer in die Google-Benutzeroberfläche ein.
3. Google löst über den Integrator die Methode sendOtp aus, ein Einmalpasswort an den Nutzer zu senden.
4. Der Nutzer erhält die SMS mit dem OTP.
5. Der Nutzer gibt dann das OTP, das er als Eingabe für capture, associateAccount und verifyOtp verwendet hat, in die Google-Oberfläche ein, um den Nutzer zu authentifizieren. Dies ist ein Authentifizierungsnachweis.

Im eigenständigen Modus wird nur die Methode verifyOtp aufgerufen, um den OTP-Wert zu überprüfen.

Das folgende Sequenzdiagramm zeigt die Interaktion zwischen dem Smartphone des Nutzers, Google und dem Integrator beim Senden eines OTP:

Ablauf der Telefonauthentifizierung (Senden des OTP)

Hinweis: Das Diagramm oben zeigt nicht die Verwendung des OTP als Eingabe für einen anderen Anruf. Dieser Wert wird jedoch als Eingabe für eine Vielzahl von Aufrufen verwendet, z. B. verifyOtp und associateAccount.

Hier ist eine Liste der Objekte im Diagramm und ihre Bedeutung:

• Nutzer: Die Person, die ihrem Google-Konto eine Zahlungsmethode hinzufügen möchte.
• Google UI: In diesem Fall eine Website oder Telefon-App von Google, über die der Kunde mit der Einrichtung einer Zahlungsmethode beginnt. Hinweis: Wenn die Google-Benutzeroberfläche eine Telefon-App ist, werden die ersten Schritte übersprungen, da das Smartphone die Telefonnummer des Nutzers bereits kennt.
• Google-Server: Der Back-End-Server bei Google, der die Authentifizierungsprüfung und andere Authentifizierungsaufgaben durchführt.
• Zahlungsintegrator-Server: Der Back-End-Server des Integrators, auf dem die Informationen des Nutzers gespeichert sind.

Da es sich um einen OTP-Authentifizierungsvorgang handelt, gehen wir bereits davon aus, dass der Nutzer die Google Smartphone-App oder -Website (Google-UI) verwendet und versucht, eine Zahlungsmethode hinzuzufügen. Hier beginnt die Initialisierung.

1. Der Nutzer wird auf der Google-Benutzeroberfläche (Smartphone oder Website) zur Eingabe seiner Telefonnummer aufgefordert.
2. Der Nutzer gibt seine Telefonnummer in die Google-Benutzeroberfläche ein.
3. Die Google-Benutzeroberfläche sendet die Nummer (sendChallenge(phoneNum)) an den Google-Server.
4. Der Google-Server sendet eine Anfrage zum Senden eines Einmalpassworts an den Zahlungsintegrator-Server (SendOtp(phoneNum)).
5. Der Zahlungsintegrator-Server sendet ein Einmalpasswort an den Nutzer.
6. Der Zahlungsintegrator-Server antwortet auf die Anfrage von Google in Punkt 5 und signalisiert, dass das OTP erfolgreich gesendet wurde.
7. Der Nutzer gibt dieses OTP in die Google-Benutzeroberfläche (Telefon oder Website) ein.
8. Das OTP wird von der Google-Benutzeroberfläche an den Google-Server gesendet, wo es schließlich zur Überprüfung an den Zahlungsintegrator gesendet wird. Dadurch wird die Identität des Nutzers bestätigt und er authentifiziert.

Authentifizierung und erneute Authentifizierung

Es gibt zwei Zeitpunkte, zu denen eine Authentifizierung erfolgen kann:

1. Anfängliche Authentifizierung: Wird zur Identifizierung und Authentifizierung eines Nutzers verwendet. Die anfängliche Authentifizierung wird als Eingabe für die Methode associateAccount verwendet.
2. Erneute Authentifizierung: wird in allen anderen Kontexten verwendet, z. B. als eigenständige Authentifizierung oder als Eingabe für capture.

Die erneute Authentifizierung unterscheidet sich von der anfänglichen Authentifizierung. Dabei geht es nicht darum, einen Nutzer neu zu identifizieren, sondern nur noch einmal zu authentifizieren. Die erneute Authentifizierung wird von Google verwendet, um den Nutzer dazu aufzufordern, nachzuweisen, dass er der Inhaber eines bestimmten Kontos ist. Dies geschieht im Ermessen von Google.

Dabei wird eine Referenz, die associationId genannt, für die ursprüngliche Verknüpfung bereitgestellt (aus dem Verknüpfungsablauf). Sie wird während des Verknüpfungsvorgangs durch den Aufruf der Methode associateAccount bereitgestellt. Das associationId identifiziert das Konto, gegen das die Anfechtung zu erwarten ist. Aus Sicherheitsgründen darf der Nutzer das betreffende Konto nicht ändern können.

Für die erneute Authentifizierung per SMS-MT OTP hält Google die Telefonnummer, die beim ursprünglichen Anruf an sendOtp angegeben wurde, als feste Nummer fest. Dies kann nicht geändert werden. Auch aus Sicherheitsgründen.

Hier ist ein Beispiel für den Ablauf, bei dem Google beschließt, vor einem Kauf eine erneute Authentifizierung durchzuführen:

Ablauf der erneuten Authentifizierung

Die Liste der Objekte und ihre Bedeutung:

• Nutzer: Die Person, die etwas kaufen möchte.
• Google UI: In diesem Fall eine Website oder Telefon-App von Google, über die der Kunde den Kauf tätigt.
• Payment Integrator UI: die kundenseitige Website oder App, über die der Nutzer mit dem Integrationspartner auf seine Kontoinformationen zugreifen kann
• Google-Server: Der Back-End-Server bei Google, der die erneute Authentifizierung und weitere Aufgaben durchführt.
• Zahlungsintegrator-Server: Der Back-End-Server des Integrators, auf dem die Informationen des Nutzers gespeichert sind.

Die erneute Authentifizierung beginnt, wenn ein Kunde mit dem Kauf beginnt. Dadurch wird ein Ablauf zur erneuten Authentifizierung des Nutzers initialisiert.

1. Der Nutzer beschließt, einen Artikel oder eine Dienstleistung zu kaufen.
2. Die Anfrage wird von der Google-Benutzeroberfläche an den Google-Server gesendet.
3. Der Google-Server sendet eine Authentifizierungsanfrage (authenticationRequest) an die Google-UI zurück.
4. Die Google-Benutzeroberfläche sendet eine Anfrage zur Authentifizierung (associationId, authenticationRequest) des Nutzers an die Benutzeroberfläche des Zahlungsintegrators.
5. Auf der Zahlungsintegrations-Benutzeroberfläche wird nach dem Nutzer gesucht, um seine Identität (LookupIdentity(associationId)) zu bestätigen.
6. Die Benutzeroberfläche des Zahlungsintegrators fordert den Nutzer auf seiner UI (Website oder App des Integrators) zur Eingabe seiner Anmeldedaten auf.
7. Die Authentifizierungsantwort wird an den Zahlungsintegrator-Server gesendet.
8. Die signierte Authentifizierungsantwort (authenticationResponse) wird an die Benutzeroberfläche des Zahlungsintegrations-Tools zurückgesendet.
9. Die Authentifizierungsantwort (authenticationResponse) wird von der Zahlungsintegrations-UI an die Google-UI gesendet.
10. Die Google-Benutzeroberfläche sendet die Antwort mit den Kaufinformationen an den Google-Server.
11. Der Server von Google sendet eine capture-Nachricht an den Zahlungsintegrator-Server (authenticationRequestId, GPT, um verfügbare Mittel zu finden).
12. Der Zahlungsintegrator-Server sendet eine Erfolgsmeldung an den Google-Server zurück.
13. Der Google-Server sendet eine Erfolgsmeldung an die Google-Benutzeroberfläche.
14. Die Artikel werden über die Google-Benutzeroberfläche an den Kunden geliefert (oder benachrichtigt, dass sie bald geliefert werden).

SMS-MO-Authentifizierung

Bei der Authentifizierung über den SMS-Dienst (Mobile Origin) wird eine SMS mit einer Authentifizierungsanfrage-ID verwendet, die vom Smartphone des Nutzers an den Zahlungsintegrator gesendet wird, um den Nutzer zu authentifizieren.

Hier ist eine Liste der Objekte im Diagramm und ihre Bedeutung:

• Nutzer: Die Person, die ihrem Google-Konto eine Zahlungsmethode hinzufügen möchte.
• Google-UI/Gerät: In diesem Fall eine Google Smartphone-App, bei der der Kunde mit der Einrichtung einer Zahlungsmethode beginnt.
• Google-Server: Der Back-End-Server bei Google, der die SMS-Anweisungen mit einer Authentifizierungsanfrage-ID (ARID) generiert und das Authentifizierungsergebnis vom Integrator empfängt.
• Payment Integrator Server: Der Back-End-Server des Integrators, der die Authentifizierungs-SMS empfängt und die ID der Authentifizierungsanfrage an Google zurückgibt.

Da es sich um einen Authentifizierungsvorgang handelt, gehen wir bereits davon aus, dass der Nutzer eine App (Google-UI) verwendet und versucht, eine Zahlungsmethode hinzuzufügen. Hier beginnt die Initialisierung.

1. Der Nutzer wählt ein tokenisiertes Zahlungsmittel aus, das er hinzufügen möchte.
2. Die Google-Benutzeroberfläche ruft den Google-Server auf, um die SMS-MO-Challenge zu initiieren.
3. Der Google-Server gibt SMS-Anweisungen zurück, die aus einem Ziel und einem Textkörper mit der ID der Authentifizierungsanfrage bestehen.
4. Die Google-Benutzeroberfläche sendet die SMS an den Zahlungsintegrator.
5. Der Zahlungsintegrator-Server ruft den Authentifizierungs-Endpunkt auf dem Google-Server mit der Authentifizierungsanfrage-ID auf.
6. Die Authentifizierungsanfrage-ID wird vom Google-Server validiert, der mit ERFOLGREICH antwortet.
7. Die Google-Benutzeroberfläche ruft den Google-Server auf, um das Ergebnis des Authentifizierungsversuchs abzurufen.
8. Antwort des Google-Servers ERFOLGREICH

Simulierte SMS-MO-Authentifizierung

Zur Durchführung von Diagnosetests des SMS-MO-Authentifizierungsvorgangs definiert Google einen Simulate SMS-Endpunkt. Dadurch muss bei der Durchführung von Testverknüpfungen in der Sandbox-Umgebung keine echte SMS gesendet und validiert werden.

Hier ist eine Liste der Objekte im Diagramm und ihre Bedeutung:

• Tester: Das ist die Person, die einen Diagnosetest der SMS-MO-Verknüpfung initiiert.
• Google UI: Eine Google-UI, in der der Tester beginnt und den Status des SMS-MO-Diagnosetests überwacht.
• Google-Server: Der Back-End-Server bei Google, der die SMS-Anweisungen mit einer Authentifizierungsanfrage-ID (ARID) generiert, die simulierte SMS-Nachricht sendet und das Authentifizierungsergebnis vom Integrator empfängt.
• Payment Integrator Server: Der Back-End-Server des Integrators, der die SMS zur simulierten Authentifizierung empfängt und die ID der Authentifizierungsanfrage an Google zurücksendet.

Dieser Ablauf umfasst folgende Schritte:

1. Der Tester startet den SMS-MO-Diagnosetest, indem er eine Testabonnenten-ID (SID) für den Test angibt. Diese SID wird im simulateSms-Aufruf an den Zahlungsintegrator enthalten.
2. Die Google-Benutzeroberfläche ruft den Google-Server auf, um die SMS-MO-Challenge zu initiieren.
3. Der Google-Server gibt SMS-Anweisungen zurück, die aus einem Ziel und einem Textkörper mit der ID der Authentifizierungsanfrage bestehen. Für diesen Test wird das Ziel von der Sandbox-HTTPS-Verbindung des Zahlungsintegrators überschrieben.
4. Die Google-Benutzeroberfläche ruft den Google-Server auf, um die simulierte SMS-Nachricht zu senden.
5. Der simulateSms-Aufruf erfolgt vom Google-Server an den Zahlungsintegrator-Server. Sowohl die Authentifizierungsanfrage-ID als auch die Abonnenten-ID (wie in Schritt 1 angegeben) sind im API-Aufruf enthalten.
6. Der Zahlungsintegrator-Server antwortet BESTÄTIGT.
7. Der Google-Server antwortet der Google-Benutzeroberfläche mit SUCCESS.
8. Der Zahlungsintegrator-Server ruft den Authentifizierungs-Endpunkt auf dem Google-Server mit der Authentifizierungsanfrage-ID auf.
9. Der Google-Server antwortet mit SUCCESS.
10. Die Google-Benutzeroberfläche ruft den Google-Server auf, um das Ergebnis des Authentifizierungsversuchs abzurufen.
11. Der Google-Server antwortet ABGESCHLOSSEN.
12. Die Google-Benutzeroberfläche ruft den Google-Server auf, um einen Zuordnungsversuch auszuführen.
13. Der associateAccount-Aufruf erfolgt vom Google-Server an den Zahlungsintegrator-Server.
14. Der Zahlungsintegrator-Server antwortet mit SUCCESS.
15. Der Google-Server antwortet mit SUCCESS.
16. Die Google-Benutzeroberfläche wird aktualisiert, um dem Tester zu zeigen, dass der SMS-MO-Diagnosetest erfolgreich abgeschlossen wurde.

Best Practices und weitere Überlegungen

Wahl der Plattformen

Durch die Bereitstellung eines Authentifizierungsvorgangs für mobile Apps und Desktop-Websites kann der Integrator die meisten Nutzer erreichen. Google empfiehlt dringend, die Android-App von Integratoren zu unterstützen, da diese die beste Nutzererfahrung bieten und zu der höchsten Conversion-Rate führen. Die in den Authentifizierungs-APIs für die Web- und Android-Apps übergebenen Parameter sind identisch.