Guía conceptual de vinculación del Acceso con Google basado en OAuth

El Acceso con Google basado en OAuth "Optimizado" tipo de vinculación agrega Acceso con Google además de Vinculación de cuentas basada en OAuth. Si usas este tipo de vinculación en tu Action, el comienza con el Acceso con Google, que te permite verificar si el usuario que la información de perfil exista en tu sistema. Si no es así, un flujo de OAuth estándar antes de comenzar a usar el servicio. Si combinas estos dos tipos de vinculación, tus usuarios podrán vincular su identidad en tu Acción con una Cuenta de Google o de terceros. Si que elijan, también pueden crear una nueva cuenta con su perfil de Google información.

La vinculación optimizada es la solución recomendada para vincular cuentas si se se aplica lo siguiente:

  • Tienes una acción que abarca varias plataformas (por ejemplo, si tu Action funciona con una app para Android).
  • Tienes un sistema de autenticación existente y quieres permitir que los usuarios vincular sus identidades con cuentas ajenas a Google. Por ejemplo, si ofreces un programa de lealtad y quieres asegurarte de que el usuario no pierda puntos acumulados en su cuenta existente.

Para verificar que la vinculación optimizada sea la solución adecuada para tu caso, consulta la Página Elige el tipo de vinculación de cuenta

Términos clave

Antes de leer sobre el funcionamiento de los vínculos optimizados, familiarízate con los siguientes términos:

  • Token de ID de Google: es una aserción firmada de la identidad de un usuario que contiene la información básica del perfil de Google de un usuario (su nombre, dirección de correo electrónico y foto de perfil). Un token de ID de Google es un Token web JSON (JWT). El siguiente es un ejemplo de un token decodificado:
{
  "sub": 1234567890,        // The unique ID of the user's Google Account
  "iss": "https://accounts.google.com",        // The token's issuer
  "aud": "123-abc.apps.googleusercontent.com", // Client ID assigned to your Actions project
  "iat": 233366400,         // Unix timestamp of the token's creation time
  "exp": 233370000,         // Unix timestamp of the token's expiration time
  "name": "Jan Jansen",
  "given_name": "Jan",
  "family_name": "Jansen",
  "email": "jan@gmail.com", // If present, the user's email address
  "locale": "en_US"
}

  • user.verificationStatus: Es una propiedad que el sistema establece para indicar si la la sesión actual tiene un usuario verificado.

  • user.accountLinkingStatus: Es una propiedad que el sistema establece para indicar si la usuario en la sesión actual tenga una identidad vinculada.

  • Escena del sistema de vinculación de cuentas: Es una escena predefinida que implementa la confirmación. de vinculación de cuentas y se puede personalizar para adaptarlos a casos de uso específicos.

  • Flujo de código de autorización: Es un flujo de OAuth 2.0 que puedes implementar con Vinculación optimizada. Este flujo requiere dos extremos:

    • Extremo de autorización: Es el extremo que presenta la IU de acceso. para los usuarios que aún no hayan accedido. Registra el consentimiento para las solicitó acceso en forma de código de autorización de corta duración.
    • Extremo de intercambio de tokens: Este extremo es responsable de dos tipos de intercambios:
      1. Intercambia un código de autorización por un token de actualización de larga duración. y uno de acceso de corta duración. Este intercambio ocurre cuando el usuario pasa por el flujo de vinculación de cuentas.
      2. Intercambia un token de actualización de larga duración por un acceso de corta duración token. Este intercambio ocurre cuando Google necesita un nuevo token de acceso porque había vencido.

  • Flujo de código implícito: Un flujo de OAuth 2.0 que puedes implementar con Vinculación optimizada. Este flujo solo requiere un extremo de autorización. Durante este flujo, Google abre tu extremo de autorización en la cuenta del usuario navegador. Si el acceso es exitoso, devuelves un token de acceso de larga duración a Google. Este token de acceso ahora se incluye en todas las solicitudes enviadas desde Asistente a tu acción.

  • Token de acceso: es un token que autoriza al servicio a acceder a partes de un de los datos del usuario. Los tokens de acceso se asocian con cada usuario individual.

  • Token de actualización: es un token que se intercambia por un token de acceso nuevo una vez por el token de acceso de corta duración venció.

Requisitos previos

Para usar el tipo de vinculación optimizada, debes tener lo siguiente:

  • Un servidor de OAuth 2.0

  • Un extremo de intercambio de token

    El extremo de intercambio de tokens se debe extender para agregar compatibilidad con el protocolos para la vinculación automática y la creación de cuentas desde un token de ID (es decir, agrega los parámetros intent=get y intent=create en las solicitudes a este extremo).

Cómo funciona

En esta sección, se describe el flujo general de la vinculación optimizada. En la siguiente sección, Flujos de vinculación optimizados, se describe los diversos flujos que pueden ocurrir según a) si habilitas o inhabilitas creación de cuentas mediante la voz y b) ya sea que utilice la forma implícita o de código de autorización.

El flujo fundamental es el siguiente:

  1. Tu acción solicita el consentimiento del usuario para acceder a su perfil de Google.
  2. Una vez que el usuario otorga su consentimiento, tu acción recibe un token de ID de Google que contiene la información del perfil de Google del usuario.
  3. Debes validar y decodificar el token para leer el contenido del perfil.
  4. Tu acción usa este token para verificar si el perfil de Google del usuario existe información en tu sistema.
    1. Si lo hace, el usuario ya accedió a tu sistema con su Cuenta de Google, y el Asistente vincula la identidad del usuario con su Cuenta de Google. El usuario puede continuar la conversación con con su cuenta vinculada.
    2. De lo contrario, consulta el paso 5.
  5. El usuario puede a) crear una cuenta nueva con su perfil de Google. o b) acceder al sistema con una cuenta diferente. El opciones que encuentran los usuarios difieren en función de si habilitas o inhabilitar la creación de cuentas mediante comandos de voz. Si el usuario elige acceder a tu con una cuenta diferente, comienza el flujo estándar de OAuth.
  6. Después de que el usuario crea una cuenta nueva o accede con otro proveedor, tu servicio devuelve un token de acceso a Google. (Si utilizas el de código de autorización, tu servicio también devuelve un token de actualización).
  7. El usuario ahora puede continuar la conversación con Asistente con su cuenta vinculada.

Flujos de vinculación optimizados

En esta sección, se repasan los distintos flujos que pueden ocurrir con la vinculación optimizada. Estos diagramas explican los flujos que se producen en el flujo de código de autorización en lugar del flujo de código implícito, y supongamos que usas Actions Builder.

Cada flujo contiene estos pasos comunes después de que el usuario invoca tu acción:

En el flujo anterior, realizas la transición a la escena del sistema de vinculación de cuentas y proporcionas una justificación personalizada. La escena le pide al usuario permiso para acceder la información de su perfil de Google. Una vez que el usuario otorga su consentimiento, Asistente envía una solicitud que contiene la información del perfil de user@gmail.com.

Los flujos posteriores a este punto difieren en función de si configuraste o no la cuenta vincular con la voz y si la información del usuario ya existe en tu en un sistema de archivos. Cada uno de estos flujos se describe en las siguientes secciones.

Flujos con la creación de cuentas de voz habilitada

En esta sección, se detallan los flujos de vinculación de cuentas que pueden ocurrir si habilitas la creación de una cuenta por voz.

Flujo 1: La información del usuario existe en tu sistema

En este caso, el usuario representado por user@gmail.com existe en tu backend. para que el extremo de intercambio de tokens devuelva un token al usuario. El nombre del usuario la identidad de tu Acción ahora está vinculada a su Cuenta de Google. El nombre del usuario la solicitud original (“Pedir lo habitual”) coincide con el intent del usuario order_drink. Luego, tu webhook se encarga de la entrega del intent coincidente y de las consultas. base de datos para el pedido habitual de user@gmail.com. Luego, el usuario puede continuar con conversación con Asistente.

Flujo 2: la información del usuario no existe y el usuario crea una cuenta

Porque habilitaste la creación de cuentas mediante voz y user@gmail.com no que existen en tu backend, el Asistente le pregunta al usuario si quiere cualquiera de las siguientes opciones:

a) Crear una cuenta nueva en tu sistema con la información de su perfil de Google. que se logra mediante la voz

b) Accede a tu sistema con una cuenta diferente.

En este caso, el usuario elige crear una cuenta nueva con la voz. Llamadas de Google el extremo de intercambio de tokens de tu servicio con una solicitud para crear una cuenta. Esta solicitud contiene el token de ID de Google, que incluye los componentes necesarios para crear una cuenta nueva. Puedes usar la información de este token (el nombre y la dirección de correo electrónico del usuario) para crearle una cuenta.

Después de crear la cuenta, el servicio muestra un token de acceso y se actualiza token de la cuenta recién creada. La identidad del usuario en tu Acción ahora es vinculado a su cuenta de Google. La solicitud original del usuario ("Pedir lo habitual") coincide con el intent del usuario order_drink. Luego, el webhook administrará entrega del intent coincidente y consultas para tu base de datos El orden habitual de user@gmail.com, que aún no existe porque el usuario es nuevo Luego, tu acción puede preguntarle al usuario qué quiere pedir.

Flujo 3: La información del usuario no existe y el usuario accede con otra cuenta

Habilitaste la creación de cuentas por voz, por lo que Asistente le preguntará al usuario si quieren realizar cualquiera de las siguientes acciones:

a) Crear una cuenta nueva en tu sistema con la información de su perfil de Google. que se logra mediante la voz

b) Accede a tu sistema con una cuenta diferente.

En este caso, el usuario elige acceder con otra cuenta, lo que inicia el flujo estándar de OAuth. Si el flujo comenzó en un dispositivo que solo usa voz, Google transfiere la ejecución a un teléfono. Luego, Google abre tu extremo de autorización en el navegador del usuario y, según tu el usuario puede elegir si desea a) acceder a tu servicio con una cuenta existente que no usa Acceso con Google o b) crear una cuenta nueva con otro proveedor. Para obtener más información sobre el flujo de OAuth, consulta el Guía conceptual de vinculación de OAuth.

Después de verificar las credenciales del usuario, tu servicio muestra un token de acceso y un token de actualización para Google. La identidad del usuario en tu Acción ahora está vinculada a una cuenta ajena a Google. Coincide con la solicitud original del usuario (“Pedir lo habitual”). el intent del usuario order_drink. Luego, el webhook administra la entrega de el intent coincidente y consulta tu base de datos para el pedido habitual de user@gmail.com, que aún no existe porque el usuario es nuevo. Luego, tu acción puede solicitar al usuario lo que quiere pedir o pedirle que configure su pedido habitual.

Flujo con la creación de cuentas de voz inhabilitada

En esta sección, se detalla el flujo de vinculación de cuentas que puede ocurrir si inhabilitas la creación de una cuenta por voz.

Flujo 4: La información del usuario no existe

No habilitaste la creación de una cuenta por voz y el usuario no existe en tu backend, por lo que comienza el flujo estándar de OAuth. Asistente abre tu de autorización en el navegador del usuario (si el flujo comenzó con una llamada dispositivo, Google transfiere la ejecución a un dispositivo con pantalla). El usuario puede elige una de las siguientes opciones: a) acceder con un proveedor diferente, si este se registró con tu servicio con una cuenta diferente o b) crea una cuenta nueva con una proveedor diferente. Para obtener más información sobre el flujo de OAuth, consulta el Guía conceptual de vinculación de OAuth.

Después de verificar las credenciales del usuario, tu servicio muestra un token de acceso y un token de actualización para Google. La identidad del usuario en tu Acción ahora está vinculada a una cuenta ajena a Google. Coincide con la solicitud original del usuario (“Pedir lo habitual”). el intent del usuario order_drink. Luego, el webhook administra la entrega de el intent coincidente y consulta tu base de datos para el pedido habitual de user@gmail.com, que aún no existe porque el usuario es nuevo. Luego, tu acción puede solicitar al que el usuario configure su pedido habitual.