Parcours utilisateur de l'authentification

Présentation

L'objectif du flux d'authentification est d'identifier l'utilisateur auprès de l'intégrateur de paiement et de l'authentifier.

L'authentification est une entrée pour d'autres méthodes. en particulier pour associateAccount et capture. Cela signifie que la preuve d'authentification est utilisée comme entrée (paramètre) pour ces deux méthodes.

Google peut également utiliser le flux d'authentification en mode autonome pour valider un utilisateur. Dans ce cas, elle n'est pas utilisée comme entrée dans un autre flux, mais uniquement pour vérifier qu'un utilisateur est en mesure d'authentifier cette identité.

Gardez à l'esprit que lors de votre intégration, Google vous aidera à choisir le mécanisme d'authentification le mieux adapté à votre produit.

Fonctionnement du flux

Il existe deux façons d'authentifier un utilisateur, chacune avec son propre flux. Au moment de l'intégration, l'intégrateur doit déterminer laquelle utiliser.

1. Authentification de la redirection
2. Authentification OTP par SMS-MT

Authentification de la redirection

Un utilisateur Google qui a besoin d'une authentification peut être redirigé vers l'application ou le site Web de l'intégrateur pour que son identité soit validée. Voici une brève présentation des étapes de cette procédure:

1. Google redirige l'utilisateur vers le site Web ou l'application Android de l'intégrateur, où il peut être authentifié.
2. L'authentification requestId (provenant de AuthenticationRequest) est utilisée comme preuve d'authentification.
3. Vous obtenez ainsi une réponse signée, appelée AuthenticationResponse.
4. Par la suite, l'application ou le site Web redirige l'utilisateur vers Google.

Remarque :En mode autonome, la réponse signée (étape 3) et la gspResult déterminent si l'authentification a réussi.

L'authentification par redirection utilise une méthode GET HTTP, avec des paramètres encodés dans l'URL pour une application Web. Elle utilise un intent Android pour l'authentification d'une application Android. Pour en savoir plus sur l'encodage, consultez la page Authentification Web. Pour les paramètres d'intent Android, consultez la page Authentification Android.

Le résultat de chacun de ces mécanismes d'authentification est une réponse signée appelée AuthenticationResponse. Cet intent doit inclure la réponse d'authentification de paiement standard Google (gspAuthenticationResponse) chiffrée et encodée afin de communiquer une méthode d'authentification réussie. En mode autonome, la gspResult et la signature permettent de déterminer si l'authentification a réussi.

Remarque :L'intégrateur doit fournir à la fois une version Web de son application Web adaptée aux mobiles et une version adaptée aux ordinateurs de bureau.

Le schéma de séquence suivant illustre les interactions entre le navigateur de l'utilisateur, Google et l'application Web de l'intégrateur:

Flux d'authentification Web de redirection

Voici la liste des objets et de ce qu'ils représentent:

• Utilisateur: il s'agit de la personne qui souhaite ajouter un mode de paiement à son compte Google.
• UI Google: dans ce cas, il s'agit de l'interface Web de Google, où le client commence à configurer un mode de paiement.
• Serveur Google: serveur backend de Google qui vérifie l'authentification, ainsi que d'autres tâches d'authentification.
• Site Web de l'intégrateur de paiement: site Web de l'intégrateur sur lequel l'utilisateur possède un compte.

Pour ce flux d'authentification, nous supposons déjà que l'utilisateur consulte le site Web de Google (UI Google) et essaie d'ajouter un mode de paiement. C'est ici que tout commence.

1. L'UI Google crée une URL d'authentification qui est envoyée au serveur Google (backend). C'est ce qui déclenche le processus d'authentification.
2. Le serveur Google crée une demande d'authentification (AuthenticationRequest).
3. Demande d'authentification envoyée à l'UI Google.
4. L'utilisateur reçoit l'invite lui indiquant qu'il doit authentifier son identifiant auprès de l'intégrateur.
5. L'utilisateur répond qu'il souhaite s'authentifier, ce qui envoie le message au site Web de l'intégrateur.
6. Le site Web de l'intégrateur de paiements demande une validation de l'identité de l'utilisateur.
7. L'utilisateur fournit un justificatif d'identité, qui est envoyé au site Web de l'intégrateur de paiements.
8. L'intégrateur crée une réponse (authenticationResponse) à la preuve qu'il a fournie (authenticationResponse encodé dans le message).
9. Cette URL de réponse est envoyée à l'utilisateur.
10. L'URL de réponse est immédiatement envoyée par l'utilisateur à l'UI Google.
11. L'UI Google envoie la réponse au serveur Google.
12. Le serveur Google interprète la réponse comme validée.

Le schéma de séquence suivant illustre les interactions entre le téléphone de l'utilisateur, Google et l'application Android de l'intégrateur:

Flux d'authentification d'application Android de redirection

Remarque :Aucun des deux diagrammes ci-dessus n'illustre l'utilisation de authenticationId comme entrée dans un autre flux, mais c'est généralement ainsi que vous l'utiliserez.

Voici les objets et ce qu'ils représentent:

• Utilisateur: il s'agit de la personne qui souhaite ajouter un mode de paiement à son compte Google.
• UI Google: dans ce cas, il s'agit de l'interface de l'application, dans laquelle le client commence à configurer un mode de paiement.
• Serveur Google: serveur backend de Google qui vérifie l'authentification, ainsi que d'autres tâches d'authentification.
• APK de l'intégrateur de paiement: application de l'intégrateur dans laquelle l'utilisateur a accès à son compte d'intégrateur.
• Serveur d'intégrateur de paiements: serveur backend de l'intégrateur sur lequel sont stockées les informations de l'utilisateur.

Comme il s'agit d'un flux d'authentification, nous supposons déjà que l'utilisateur utilise une application (UI Google) et essaie d'ajouter un mode de paiement. C'est ici que commence l'initialisation.

1. L'UI Google crée un appel d'authentification qui est envoyé au serveur Google (backend).
2. Le serveur Google crée une demande d'authentification (AuthenticationRequest).
3. Le serveur Google envoie un APK d'appel à l'UI (application) Google et demande une authentification.
4. L'UI Google envoie les informations sur l'utilisateur au fichier APK de l'intégrateur de paiements (AUTHENTICATE_V1(authReq)).
5. L'APK de l'intégrateur de paiements envoie la requête (authReq) au serveur de l'intégrateur de paiement.
6. Le serveur de l'intégrateur de paiements renvoie une question d'authentification à l'APK de l'intégrateur de paiements.
7. Le fichier APK de l'intégrateur de paiements renvoie la question d'authentification à l'utilisateur.
8. L'utilisateur fournit un justificatif d'identité, qui est envoyé à l'APK de l'intégrateur de paiements.
9. Cette preuve est ensuite envoyée au serveur de l'intégrateur de paiements.
10. Le serveur crée un élément authenticationResponse signé.
11. La réponse d'authentification aboutit, et un message authResp est envoyé à l'APK de l'intégrateur de paiements.
12. Le message de réussite (authResp) est envoyé à l'UI Google par l'APK de l'intégrateur de paiements.
13. L'UI Google envoie la réponse au serveur Google.
14. Le serveur Google interprète la réponse positive.

Authentification OTP par SMS-MT

Autre méthode d'authentification : service de messages courts, connexion mobile interrompue, mot de passe à usage unique (SMS-MT OTP). Ce mécanisme utilise le numéro de téléphone de l'utilisateur pour lui envoyer un mot de passe à usage unique à des fins d'authentification. Google demande à l'intégrateur d'envoyer un mot de passe à usage unique au numéro de téléphone de l'utilisateur. Une fois que celui-ci l'a reçu, puis saisi ces informations dans l'interface Google, l'utilisateur est validé.

Cela inclut les étapes suivantes:

1. L'interface utilisateur de Google invite l'utilisateur à saisir le numéro de téléphone déjà enregistré auprès de l'intégrateur.
2. L'utilisateur saisit un numéro de téléphone dans l'interface utilisateur Google.
3. Google déclenche l'intégrateur (appelle la méthode sendOtp) pour envoyer un mot de passe à usage unique (OTP) à l'utilisateur.
4. L'utilisateur reçoit le SMS avec le mot de passe à usage unique.
5. L'utilisateur saisit ensuite le mot de passe à usage unique (utilisé pour capture, associateAccount et verifyOtp) qu'il a reçu dans l'interface Google afin d'authentifier l'utilisateur. Ceci est une preuve d'authentification.

En mode autonome, seule la méthode verifyOtp est appelée pour vérifier la valeur de l'OTP.

Le schéma de séquence suivant illustre les interactions entre le téléphone de l'utilisateur, Google et l'intégrateur lors de l'envoi d'un mot de passe à usage unique:

Flux d'authentification par téléphone (envoi de l'OTP)

Remarque :Le schéma ci-dessus n'illustre pas l'utilisation du mot de passe à usage unique en entrée d'un autre appel. Cependant, il peut être utilisé comme entrée pour divers appels, tels que verifyOtp et associateAccount.

Voici une liste d'objets dans le schéma et ce qu'ils représentent:

• Utilisateur: il s'agit de la personne qui souhaite ajouter un mode de paiement à son compte Google.
• UI Google: dans ce cas, il s'agit d'un site Web Google ou d'une application pour téléphone où le client commence à configurer un mode de paiement. Remarque: Si l'UI Google est une application pour téléphone, les premières étapes seront ignorées, car le téléphone connaît déjà le numéro de téléphone de l'utilisateur.
• Serveur Google: serveur backend de Google qui vérifie l'authentification, ainsi que d'autres tâches d'authentification.
• Serveur d'intégrateur de paiements: serveur backend de l'intégrateur sur lequel sont stockées les informations de l'utilisateur.

Comme il s'agit d'un flux d'authentification OTP, nous supposons déjà que l'utilisateur consulte une application ou un site Web Google (interface utilisateur Google) et essaie d'ajouter un mode de paiement. C'est ici que commence l'initialisation.

1. L'UI Google (téléphone ou site Web) invite l'utilisateur à fournir son numéro de téléphone.
2. L'utilisateur saisit son numéro de téléphone dans l'interface utilisateur Google.
3. L'UI Google envoie le numéro (sendChallenge(phoneNum)) au serveur Google.
4. Le serveur Google envoie une demande au serveur de l'intégrateur de paiements (SendOtp(phoneNum)) pour envoyer un mot de passe à usage unique.
5. Le serveur d'intégration des paiements envoie un mot de passe à usage unique (OTP) à l'utilisateur.
6. Le serveur de l'intégrateur de paiements répond à la demande de Google au point 5, indiquant que l'OTP a bien été envoyé.
7. L'utilisateur saisit cet OTP dans l'UI Google (téléphone ou site Web).
8. L'UI Google envoie l'OTP au serveur Google, où il est finalement transmis à l'intégrateur de paiements pour validation. Cette opération permet de vérifier l'identité de l'utilisateur et de l'authentifier.

Authentification et réauthentification

L'authentification peut avoir lieu à deux moments:

1. Authentification initiale : permet d'identifier et d'authentifier un utilisateur. L'authentification initiale est utilisée comme entrée dans la méthode associateAccount.
2. Réauthentification : utilisée dans tous les autres contextes, par exemple de façon autonome ou en tant qu'entrée dans capture.

La réauthentification diffère de l'authentification initiale. Elle ne souhaite jamais restaurer l'identification d'un utilisateur, simplement pour s'authentifier de nouveau. Google utilise la réauthentification pour demander à l'utilisateur de prouver qu'il possède un compte particulier. Cette opération est effectuée à sa discrétion.

Dans ce processus, une référence, appelée associationId, est fournie à l'association d'origine (à partir du flux d'association). Il est fourni via l'appel à la méthode associateAccount lors du processus d'association. L'associationId identifie le compte à contester. Pour des raisons de sécurité, l'utilisateur ne doit pas pouvoir modifier le compte concerné par la question d'authentification.

Pour la réauthentification OTP via SMS-MT, Google conserve le numéro de téléphone fourni lors de l'appel initial à sendOtp sous la forme d'un numéro fixe. Pour des raisons de sécurité, vous ne pourrez plus modifier ce paramètre.

Voici un exemple de procédure dans laquelle Google décide d'interroger (une nouvelle authentification) avant d'effectuer un achat:

Flux de réauthentification

Voici la liste des objets et de ce qu'ils représentent:

• Utilisateur: il s'agit de la personne qui souhaite effectuer un achat.
• UI Google: dans ce cas, il s'agit d'un site Web Google ou d'une application pour téléphone où le client commence à effectuer l'achat.
• Interface utilisateur de l'intégrateur de paiement: site Web ou application destiné aux clients, sur lequel l'utilisateur peut accéder aux informations de son compte avec l'intégrateur.
• Serveur Google: serveur backend de Google qui effectue les vérifications de réauthentification, ainsi que d'autres tâches.
• Serveur d'intégrateur de paiements: serveur backend de l'intégrateur sur lequel sont stockées les informations de l'utilisateur.

Le flux de réauthentification commence lorsqu'un client commence à effectuer un achat. Cette opération initialise un flux pour réauthentifier l'utilisateur.

1. L'utilisateur décide d'acheter un article ou un service.
2. La requête est envoyée de l'UI Google au serveur Google.
3. Le serveur Google renvoie une demande d'authentification (authenticationRequest) à l'UI Google.
4. L'UI Google envoie une requête à l'UI de l'intégrateur de paiements pour authentifier l'utilisateur (associationId, authenticationRequest).
5. L'interface utilisateur de l'intégrateur de paiements recherche l'utilisateur pour valider son identité (LookupIdentity(associationId)).
6. Celle-ci invite l'utilisateur à saisir ses identifiants sur son interface (site Web ou application de l'intégrateur).
7. La réponse d'authentification est envoyée au serveur de l'intégrateur de paiements.
8. La réponse d'authentification signée (authenticationResponse) est renvoyée à l'interface utilisateur de l'intégrateur de paiements.
9. La réponse d'authentification (authenticationResponse) est envoyée de l'UI de l'intégrateur de paiements à l'UI de Google.
10. L'interface utilisateur de Google envoie la réponse contenant les informations d'achat au serveur Google.
11. Le serveur de Google envoie un message capture (pour trouver les fonds disponibles) au serveur de l'intégrateur de paiements (authenticationRequestId, GPT, montant).
12. Le serveur d'intégration des paiements renvoie un message de réussite au serveur Google.
13. Le serveur de Google envoie un message de réussite à l'interface utilisateur de Google.
14. L'interface utilisateur de Google transmet le ou les articles au client (ou l'informe qu'il sera bientôt livré).

Authentification par SMS-MO

Le flux d'authentification à l'origine du service de messages courts sur mobile utilise un SMS contenant un ID de demande d'authentification envoyé du téléphone de l'utilisateur à l'intégrateur de paiement pour authentifier l'utilisateur.

Voici une liste d'objets dans le schéma et ce qu'ils représentent:

• Utilisateur: il s'agit de la personne qui souhaite ajouter un mode de paiement à son compte Google.
• Interface utilisateur/Appareil Google: dans ce cas, il s'agit d'une application pour téléphone Google dans laquelle le client commence à configurer un mode de paiement.
• Serveur Google: serveur backend de Google qui génère les instructions SMS avec un ID de demande d'authentification (ARID) et reçoit le résultat d'authentification de l'intégrateur.
• Serveur d'intégrateur de paiement: serveur backend de l'intégrateur qui reçoit le SMS d'authentification et renvoie l'ID de demande d'authentification à Google.

Comme il s'agit d'un flux d'authentification, nous supposons déjà que l'utilisateur utilise une application (UI Google) et essaie d'ajouter un mode de paiement. C'est ici que commence l'initialisation.

1. L'utilisateur sélectionne un instrument tokenisé à ajouter.
2. L'UI Google appelle le serveur Google pour lancer le défi SMS-MO.
3. Le serveur Google renvoie des instructions SMS, composées d'une destination et d'un corps contenant l'ID de demande d'authentification.
4. L'UI Google envoie le SMS à l'intégrateur de paiements.
5. Le serveur de l'intégrateur de paiements appelle le point de terminaison authenticationResultNotification sur le serveur Google avec l'ID de demande d'authentification.
6. L'ID de demande d'authentification est validé par le serveur Google, qui répond "SUCCESS".
7. L'UI Google appelle le serveur Google pour obtenir le résultat de la tentative d'authentification.
8. Réponse du serveur Google : SUCCESS.

Authentification par SMS-MO simulée

Afin d'effectuer des tests de diagnostic du flux d'authentification SMS-MO, Google définit un point de terminaison Simuler un SMS. Ainsi, il n'est plus nécessaire d'envoyer et de valider un vrai SMS lorsque vous effectuez des associations de test dans l'environnement de bac à sable.

Voici une liste d'objets dans le schéma et ce qu'ils représentent:

• Testeur: personne qui lance un test de diagnostic d'association SMS-MO.
• UI Google: interface Google sur laquelle le testeur démarre et surveille l'état du test de diagnostic SMS-MO.
• Serveur Google: serveur backend de Google qui génère les instructions SMS avec un ID de demande d'authentification (ARID), envoie le SMS simulé et reçoit le résultat d'authentification de l'intégrateur.
• Serveur d'intégrateur de paiement: serveur backend de l'intégrateur qui reçoit le SMS d'authentification simulé et renvoie l'ID de demande d'authentification à Google.

Les étapes de ce flux sont les suivantes:

1. Le testeur lance le test de diagnostic SMS-MO en fournissant un ID d'abonné (SID) test à utiliser pour ce test. Ce SID sera inclus dans l'appel simulateSms envoyé à l'intégrateur de paiements.
2. L'UI Google appelle le serveur Google pour lancer le défi SMS-MO.
3. Le serveur Google renvoie des instructions SMS, composées d'une destination et d'un corps contenant l'ID de demande d'authentification. Pour les besoins de ce test, la destination sera remplacée par la connexion HTTPS du bac à sable de l'intégrateur de paiements.
4. L'UI Google appelle le serveur Google pour envoyer le SMS simulé.
5. Le serveur Google envoie l'appel simulateSms au serveur de l'intégrateur de paiements. L'ID de demande d'authentification et l'ID d'abonné (tels que fournis à l'étape 1) sont inclus dans l'appel d'API.
6. Le serveur de l'intégrateur de paiements répond "ACKNOWLEDGED".
7. Le serveur Google envoie une réponse SUCCESS à l'interface utilisateur Google.
8. Le serveur de l'intégrateur de paiements appelle le point de terminaison authenticationResultNotification sur le serveur Google avec l'ID de demande d'authentification.
9. Le serveur Google répond : SUCCESS.
10. L'UI Google appelle le serveur Google pour obtenir le résultat de la tentative d'authentification.
11. Le serveur Google répond "COMPLETED".
12. L'UI Google appelle le serveur Google pour exécuter une tentative d'association.
13. Le serveur Google envoie l'appel associateAccount au serveur de l'intégrateur de paiements.
14. Le serveur d'intégrateur de paiements renvoie "SUCCESS".
15. Le serveur Google répond : SUCCESS.
16. L'interface utilisateur Google est mise à jour pour indiquer au testeur que le test de diagnostic SMS-MO a bien été effectué.

Bonnes pratiques et autres considérations

Choix des plates-formes

Fournir un flux d'authentification Web pour les applications mobiles et les ordinateurs de bureau permettra à l'intégrateur de toucher le plus grand nombre d'utilisateurs. Google recommande vivement aux intégrateurs de prendre en charge l'application Android, car elle offre la meilleure expérience utilisateur possible et entraîne le taux de conversion le plus élevé. Les paramètres transmis dans les API d'authentification pour le Web et les applications Android sont identiques.