Flujo de usuarios de autenticación

Descripción general

El propósito del flujo de autenticación es identificar y autenticar al usuario ante el integrador de pagos (integrador).

La autenticación es una entrada a otros métodos. Especialmente para associateAccount y capture. Esto significa que la prueba de autenticación se utiliza como una entrada (parámetro) para esos dos métodos.

Google también puede usar el flujo de autenticación en modo independiente para verificar a un usuario. En este caso, no se usa como entrada para ningún otro flujo, sino solo para verificar que un usuario pueda autenticar esta identidad.

Ten en cuenta que durante la integración, Google trabajará contigo para elegir el mecanismo de autenticación que mejor se adapte a tu producto.

Cómo funciona el flujo

Existen dos maneras de autenticar a un usuario, cada una con su propio flujo. En el momento de la integración, el integrador debe determinar cuál usar.

  1. Autenticación de redireccionamiento
  2. Autenticación con OTP de SMS-MT

Autenticación de redireccionamiento

Es posible que se redireccione a un usuario de Google que necesita autenticación a la app o al sitio web del integrador para que se verifique su identidad. A continuación, se incluye una breve descripción general de los pasos de este flujo:

  1. Google redirecciona al usuario a la app web o para Android del integrador, en la que se puede autenticar.
  2. Para realizar la autenticación, se usa el requestId de autenticación (de AuthenticationRequest) como prueba de la autenticación.
  3. Esto da como resultado una respuesta firmada, llamada AuthenticationResponse.
  4. Luego, la app o el sitio web redirecciona al usuario de vuelta a Google.

La autenticación con redireccionamiento usa un método GET HTTP, con parámetros codificados en la URL de una aplicación web. Usa un Intent de Android para la autenticación de una aplicación para Android. Para obtener más detalles sobre la codificación, consulta Autenticación web. Para ver los parámetros de intents de Android, consulta Autenticación de Android.

El resultado de cada uno de estos mecanismos de autenticación es una respuesta firmada llamada AuthenticationResponse. Este intent debe incluir la respuesta de autenticación de pagos estándar de Google codificada y encriptada (gspAuthenticationResponse) para comunicar una autenticación exitosa. Si se usan en modo independiente, gspResult y la firma se usan para determinar la autenticación correcta.

En el siguiente diagrama de secuencias, se muestra la interacción entre el navegador del usuario, Google y la aplicación web del integrador:

Flujo de autenticación web de redireccionamiento

Flujo de autenticación web

Esta es una lista de los objetos y lo que representan:

  • Usuario: Es la persona que desea agregar una forma de pago a su Cuenta de Google.
  • IU de Google: En este caso, es la interfaz web de Google, donde el cliente comienza a configurar una forma de pago.
  • Servidor de Google: El servidor de backend de Google que realiza la verificación de autenticación junto con otras tareas de autenticación.
  • Web de integrador de pagos: Es el sitio web del integrador en el que el usuario tiene una cuenta.

Para este flujo de autenticación, ya suponemos que el usuario está en el sitio web de Google (IU de Google) y trata de agregar una forma de pago. Aquí es donde todo comienza.

  1. La IU de Google crea una URL de autenticación que se envía al servidor de Google (backend). Esto es lo que activa el proceso de autenticación.
  2. El servidor de Google crea una solicitud de autenticación (AuthenticationRequest).
  3. La solicitud de autenticación enviada a la IU de Google.
  4. El usuario recibe el mensaje que le solicita autenticar su ID con el integrador.
  5. El usuario responde que quiere autenticarse, lo que envía ese mensaje al sitio web del integrador.
  6. El sitio web de la integración de pagos solicita la verificación de la identidad del usuario.
  7. El usuario proporciona una prueba de su identidad, que se envía al sitio web del integrador de pagos.
  8. El integrador crea una respuesta (authenticationResponse) a la evidencia que se le proporcionó (con el authenticationResponse codificado en el mensaje).
  9. Esta URL de respuesta se envía al usuario.
  10. La URL de respuesta se envía de inmediato del usuario a la IU de Google.
  11. La IU de Google envía la respuesta al servidor de Google.
  12. El servidor de Google interpreta la respuesta como verificada.

En el siguiente diagrama de secuencias, se muestra la interacción entre el teléfono del usuario, Google y la aplicación para Android del integrador:

Flujo de autenticación de apps para Android de redireccionamiento

Flujo de autenticación de apps para Android

Estos son los objetos y lo que representan:

  • Usuario: Es la persona que desea agregar una forma de pago a su Cuenta de Google.
  • IU de Google: En este caso, es la interfaz de la app, con la que el cliente comienza a configurar una forma de pago.
  • Servidor de Google: El servidor de backend de Google que realiza la verificación de autenticación junto con otras tareas de autenticación.
  • APK de integrador de pagos: Es la app del integrador en la que el usuario tiene acceso a su cuenta del integrador.
  • Servidor de integración de pagos: Es el servidor de backend del integrador en el que se almacena la información del usuario.

Dado que este es un flujo de autenticación, ya asumimos que el usuario utiliza una app (IU de Google) y trata de agregar una forma de pago. Aquí es donde comienza la inicialización.

  1. La IU de Google crea una llamada de autenticación que se envía al servidor de Google (backend).
  2. El servidor de Google crea una solicitud de autenticación (AuthenticationRequest).
  3. El servidor de Google envía un APK de llamada a la IU (app) de Google y solicita la autenticación.
  4. La IU de Google envía la información del usuario al APK de Payment Integrator (AUTHENTICATE_V1(authReq)).
  5. El APK de la integración de pagos envía la solicitud (authReq) al servidor de esta función.
  6. El servidor de Payment Integrator envía una verificación al APK de Payment Integrator.
  7. El APK de integración de pagos envía el desafío al usuario.
  8. El usuario proporciona una prueba de su identidad, que se envía al APK de la integración de pagos.
  9. Luego, el comprobante se envía al servidor de la integración de pagos.
  10. El servidor crea un authenticationResponse firmado.
  11. La respuesta de autenticación es correcta y se envía un mensaje authResp al APK de Payment Integrator.
  12. Se envía el mensaje de éxito (authResp) desde el APK de Payment Integrator a la IU de Google.
  13. La IU de Google envía la respuesta al servidor de Google.
  14. El servidor de Google interpreta la respuesta correcta.

Autenticación de OTP de SMS-MT

Otro método de autenticación es el servicio de mensajes cortos, la contraseña de un solo uso terminada en el dispositivo móvil (SMS-MT OTP). Este mecanismo utiliza el número de teléfono del usuario para enviarle una contraseña de un solo uso para la autenticación. Google le solicita al integrador que envíe una OTP al número de teléfono del usuario. Una vez que este la reciba y, luego, la ingrese en la interfaz de Google, se verificará al usuario.

Esto incluye los siguientes pasos:

  1. La interfaz de usuario (IU) de Google le solicita al usuario que ingrese el número de teléfono, que ya está registrado en el integrador.
  2. El usuario ingresa un número de teléfono en la IU de Google.
  3. Google activa el integrador (llama al método sendOtp) para enviar una contraseña de un solo uso (OTP) al usuario.
  4. El usuario recibe el mensaje SMS con la OTP.
  5. Luego, el usuario debe ingresar en la interfaz de Google la OTP (que se usa como entrada para capture, associateAccount y verifyOtp) para autenticar al usuario. Esta es una prueba de autenticación.

En el modo independiente, solo se llamará al método verifyOtp para verificar el valor de la OTP.

En el siguiente diagrama de secuencias, se muestra la interacción entre el teléfono del usuario, Google y el integrador cuando se envía una OTP:

Flujo de autenticación por teléfono (OTP de envío)

Flujo de autenticación por teléfono (OTP)

A continuación, se muestra una lista de objetos en el diagrama y lo que representan:

  • Usuario: Es la persona que desea agregar una forma de pago a su Cuenta de Google.
  • IU de Google: En este caso, es un sitio web de Google o una aplicación para teléfonos donde el cliente comienza a configurar una forma de pago. Nota: Si la IU de Google es una aplicación para teléfonos, se omitirán los primeros pasos porque el teléfono ya conoce el número de teléfono del usuario.
  • Servidor de Google: El servidor de backend de Google que realiza la verificación de autenticación junto con otras tareas de autenticación.
  • Servidor de integración de pagos: Es el servidor de backend del integrador en el que se almacena la información del usuario.

Dado que este es un flujo de autenticación con OTP, ya asumimos que el usuario está en un sitio web o una app para teléfonos de Google (IU de Google) y está intentando agregar una forma de pago. Aquí es donde comienza la inicialización.

  1. La IU de Google (teléfono o sitio web) solicita al usuario su número de teléfono.
  2. El usuario ingresa su número de teléfono en la IU de Google.
  3. La IU de Google envía el número (sendChallenge(phoneNum)) al servidor de Google.
  4. El servidor de Google envía una solicitud al servidor de integración de pagos (SendOtp(phoneNum)) para que se envíe una contraseña de un solo uso.
  5. El servidor de integración de pagos envía una contraseña de un solo uso (OTP) al usuario.
  6. El servidor de integración de pagos responde la solicitud de Google en el paso 5, lo que indica que la OTP se envió correctamente.
  7. El usuario ingresa esta OTP en la IU de Google (teléfono o sitio web).
  8. La IU de Google envía la OTP al servidor de Google, donde finalmente se envía al integrador de pagos para su verificación. Esto verifica la identidad del usuario y lo autentica.

Autenticación y reautenticación

La autenticación puede ocurrir en los siguientes dos momentos:

  1. Autenticación inicial: se usa para identificar y autenticar a un usuario. La autenticación inicial se usa como entrada al método associateAccount.
  2. Reautenticación: Se usa en todos los demás contextos, como independiente o como entrada de capture.

La reautenticación es diferente de la autenticación inicial. Nunca desea volver a identificar a un usuario, simplemente volver a autenticarse. Google utiliza la reautenticación para desafiar al usuario a demostrar que es el propietario de una cuenta en particular. Esto sucede a discreción de Google.

En este proceso, se proporciona una referencia, llamada associationId, a la asociación original (desde el flujo de asociación). Se proporciona a través de la llamada al método associateAccount durante el flujo de asociación. El associationId identifica la cuenta en la que se debe competir. Por razones de seguridad, el usuario no debe poder cambiar la cuenta en cuestión.

Para la reautenticación con OTP de SMS-MT, Google conserva el número de teléfono proporcionado durante la llamada original a sendOtp como número fijo. Por motivos de seguridad, no se puede cambiar.

El siguiente es un ejemplo de flujo en el que Google decide refutar (volver a autenticar) antes de realizar una compra:

Flujo de reautenticación

Flujo de reautenticación

La lista de objetos y lo que representan es la siguiente:

  • Usuario: Es la persona que desea realizar una compra.
  • IU de Google: En este caso, es un sitio web o una aplicación para teléfonos de Google donde el cliente comienza a realizar la compra.
  • IU del integrador de pagos: Es el sitio web o la app para el cliente en el que el usuario puede acceder a la información de su cuenta mediante el integrador.
  • Servidor de Google: Es el servidor de backend de Google que realiza la verificación de reautenticación, junto con otras tareas.
  • Servidor de integración de pagos: Es el servidor de backend del integrador en el que se almacena la información del usuario.

El flujo de reautenticación comienza cuando un cliente comienza a realizar una compra. Esto inicializa un flujo para volver a autenticar al usuario.

  1. El usuario decide comprar un artículo o servicio.
  2. La solicitud se envía de la IU de Google al servidor de Google.
  3. El servidor de Google devuelve una solicitud de autenticación (authenticationRequest) a la IU de Google.
  4. La IU de Google envía una solicitud a la IU de Payment Integrator para autenticar (associationId, authenticationRequest) al usuario.
  5. La IU de Payment Integrator busca al usuario para verificar su identidad (LookupIdentity(associationId)).
  6. La IU de Payment Integrator solicita al usuario las credenciales en su IU (sitio web o app del integrador).
  7. La respuesta de autenticación se envía al servidor de la integración de pagos.
  8. La respuesta de autenticación firmada (authenticationResponse) se envía de vuelta a la IU de Payment Integrator.
  9. La respuesta de autenticación (authenticationResponse) se envía desde la IU de Payment Integrator a la IU de Google.
  10. La IU de Google envía la respuesta con la información de la compra al servidor de Google.
  11. El servidor de Google envía un mensaje de capture (para encontrar los fondos disponibles) al servidor de integración de pagos (authenticationRequestId, GPT, importe).
  12. El servidor de integración de pagos envía un mensaje de éxito al servidor de Google.
  13. El servidor de Google envía un mensaje de éxito a la IU de Google.
  14. La IU de Google entrega los artículos al cliente (o le notifica que se entregarán pronto).

Autenticación de SMS-MO

El servicio de mensajes cortos, el flujo de autenticación originado por dispositivos móviles, utiliza un SMS que contiene un ID de solicitud de autenticación enviado desde el teléfono del usuario al integrador de pagos para autenticarlo.

Flujo de autenticación de SMS-MO

A continuación, se muestra una lista de objetos en el diagrama y lo que representan:

  • Usuario: Es la persona que desea agregar una forma de pago a su Cuenta de Google.
  • IU o dispositivo de Google: En este caso, es una aplicación para teléfonos de Google en la que el cliente comienza a configurar una forma de pago.
  • Servidor de Google: Es el servidor de backend de Google que genera las instrucciones de SMS con un ID de solicitud de autenticación (ARID) y recibe el resultado de la autenticación del integrador.
  • Servidor de integración de pagos: Es el servidor de backend del integrador que recibe el SMS de autenticación y muestra el ID de solicitud de autenticación a Google.

Dado que este es un flujo de autenticación, ya asumimos que el usuario utiliza una app (IU de Google) y trata de agregar una forma de pago. Aquí es donde comienza la inicialización.

  1. El usuario selecciona un instrumento con token para agregarlo.
  2. La IU de Google llama al servidor de Google para iniciar el desafío SMS-MO.
  3. El servidor de Google muestra instrucciones de SMS, que consisten en un destino y un cuerpo que contiene el ID de la solicitud de autenticación.
  4. La IU de Google envía el SMS al integrador de pagos.
  5. El servidor de integrador de pagos llama al extremo AuthenticationResultNotification en el servidor de Google con el ID de solicitud de autenticación.
  6. El servidor de Google valida el ID de solicitud de autenticación, y este responde con ÉXITO.
  7. La IU de Google llama al servidor de Google para obtener el resultado del intento de autenticación.
  8. La respuesta del servidor de Google es CORRECTAMENTE.

Autenticación simulada de SMS-MO

Para realizar pruebas de diagnóstico del flujo de autenticación de SMS-MO, Google define un extremo Simular SMS. Esto elimina la necesidad de que se envíe y se valide un SMS real al realizar asociaciones de prueba en el entorno de la zona de pruebas.

Flujo de autenticación de SMS-MO simulado

A continuación, se muestra una lista de objetos en el diagrama y lo que representan:

  • Verificador: Es la persona que inicia una prueba de diagnóstico de asociación de SMS-MO.
  • IU de Google: Es una IU de Google en la que el verificador inicia y supervisa el estado de la prueba de diagnóstico de SMS-MO.
  • Servidor de Google: Es el servidor de backend de Google que genera las instrucciones de SMS con un ID de solicitud de autenticación (ARID), envía el mensaje SMS simulado y recibe el resultado de la autenticación del integrador.
  • Servidor de integración de pagos: Es el servidor de backend del integrador que recibe el SMS de autenticación simulado y muestra el ID de solicitud de autenticación a Google.

Los pasos de este flujo son los siguientes:

  1. El Verificador comienza la prueba de diagnóstico de SMS-MO proporcionando un ID de suscriptor (SID) de prueba para usarlo en la prueba. Este SID se incluirá en la llamada de simulateSms al integrador de pagos.
  2. La IU de Google llama al servidor de Google para iniciar el desafío SMS-MO.
  3. El servidor de Google muestra instrucciones de SMS, que consisten en un destino y un cuerpo que contiene el ID de la solicitud de autenticación. Para los fines de esta prueba, la conexión HTTPS de la zona de pruebas del integrador de pagos anulará el destino.
  4. La IU de Google llama al servidor de Google para enviar el mensaje SMS simulado.
  5. La llamada simulateSms se realiza desde el servidor de Google al servidor de la integración de pagos. Tanto el ID de solicitud de autenticación como el ID de suscriptor (como se proporciona en el paso 1) se incluyen en la llamada a la API.
  6. El servidor de integración de pagos responde ACKNOWLEDGED.
  7. El servidor de Google responde CORRECTAMENTE a la IU de Google.
  8. El servidor de integrador de pagos llama al extremo AuthenticationResultNotification en el servidor de Google con el ID de solicitud de autenticación.
  9. El servidor de Google responde con ÉXITO.
  10. La IU de Google llama al servidor de Google para obtener el resultado del intento de autenticación.
  11. El servidor de Google responde como COMPLETED.
  12. La IU de Google llama al servidor de Google para ejecutar un intento de asociación.
  13. La llamada associateAccount se realiza desde el servidor de Google al servidor de la integración de pagos.
  14. El servidor de integración de pagos responde CORRECTAMENTE.
  15. El servidor de Google responde con ÉXITO.
  16. La IU de Google se actualiza para indicarle al Verificador que la prueba de diagnóstico de SMS-MO se completó correctamente.

Prácticas recomendadas y otras consideraciones

Elección de plataformas

Proporcionar un flujo de autenticación web para computadoras y una app para dispositivos móviles permitirá al integrador llegar a la mayor cantidad de usuarios. Google recomienda que los integradores admitan la aplicación para Android, ya que proporcionan la mejor experiencia del usuario y generan el porcentaje de conversiones más alto. Los parámetros que se pasan en las APIs de autenticación para las aplicaciones web y para Android son los mismos.