Guía de conceptos de OAuth y Acceso con Google (Dialogflow)

El tipo de vinculación de OAuth y Acceso con Google agrega Acceso con Google a los 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.

OAuth y Acceso con Google 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 OAuth y el Acceso con Google sean la solución adecuada para ti, consulta la Página Elige el tipo de vinculación de cuenta

Términos clave

Antes de leer sobre cómo funcionan OAuth y el Acceso con Google, 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"
}
  • Intent de asistente de acceso a la cuenta: Es un intent de ayuda que llamas para solicitarlo. un flujo de vinculación de cuentas desde Asistente. Para obtener más información, consulta Acceso a la cuenta.
    • Cadena de contexto: Es una cadena personalizada que agregas a la cuenta. intent de asistente de acceso que le indica al usuario por qué deseas vincular a su cuenta.
  • Flujo de código de autorización: Es un flujo de OAuth 2.0 que puedes implementar con OAuth y Acceso con Google. 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 OAuth y Acceso con Google. 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 que se envían desde el 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 de OAuth y Acceso con Google, necesitas lo siguiente:

  • Un servidor de OAuth 2

  • 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 OAuth y el Acceso con Google. En la siguiente sección, Flujos de OAuth y GSI, 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 el 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 OAuth y GSI

En esta sección, se explican los distintos flujos que pueden ocurrir con OAuth y GSI. 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 supón que usas Dialogflow como la solución de comprensión del lenguaje natural para tu acción.

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

En el flujo anterior, llamas al intent de ayuda actions.intent.SIGN_IN con un la cadena de contexto que personalizas. Este intent solicita al usuario permiso para acceder la información de su perfil de Google. Una vez que el usuario otorga su consentimiento, el 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 personalizado 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 el 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 desea 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 personalizado order_drink.. Luego, webhook 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 el 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 de conceptos 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”). al intent personalizado order_drink.. Luego, webhook administrará 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 de conceptos 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”). al intent personalizado order_drink.. Luego, webhook administrará 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.