Descripción general

Elige tu ruta de integración

Selecciona la ruta que mejor se adapte a tus necesidades:

Ruta	Ideal para	Más información
Universal Commerce Protocol (UCP)	Comerciantes y minoristas	Documentos del UCP
Vinculación de cuentas estándar	Casa inteligente, TV y YouTube	Documentos

Nota: Estas rutas de integración son complementarias. Si implementas el UCP, te recomendamos que revises tanto la guía de vinculación de identidad del UCP para conocer los requisitos específicos del producto como esta documentación para obtener detalles sobre la implementación principal de OAuth.

La vinculación de cuentas permite que los titulares de Cuentas de Google se conecten a tus servicios de forma rápida, fluida y segura. Puedes implementar la vinculación de cuentas de Google para compartir los datos de un usuario de tu plataforma con las apps y los servicios de Google.

El protocolo seguro OAuth 2.0 te permite vincular de forma segura la Cuenta de Google de un usuario con su cuenta en tu plataforma, lo que otorga a las aplicaciones y los dispositivos de Google acceso a tus servicios.

Los usuarios pueden vincular o desvincular sus cuentas y, de manera opcional, crear una nueva en tu plataforma con la vinculación de cuentas de Google.

Casos de uso

Estos son algunos de los motivos para implementar la vinculación de cuentas de Google:

• Compartir los datos de un usuario de tu plataforma con las apps y los servicios de Google

• Realizar la integración con Google Shopping y las plataformas de IA (Búsqueda, Gemini) mediante el Universal Commerce Protocol (UCP).

• Reproducir tu contenido de video y películas con Google TV.

• Administrar y controlar los dispositivos conectados de la casa inteligente de Google con la app de Google Home y Asistente de Google, "Hey Google, enciende las luces"

• Crear experiencias y funcionalidades personalizadas de Asistente de Google para los usuarios con Acciones conversacionales, "Hey Google, pide mi pedido habitual de Starbucks".

• Permitir que los usuarios ganen recompensas mirando transmisiones en vivo aptas en YouTube después de vincular su Cuenta de Google a una cuenta de socio de recompensas.

• Completar previamente las cuentas nuevas durante el registro con datos compartidos de forma consensual desde un perfil de Cuenta de Google.

Funciones admitidas

La vinculación de cuentas de Google admite las siguientes funciones:

• Compartir tus datos rápidamente con el flujo implícito de vinculación de OAuth

  Precaución: El flujo implícito no es compatible con los flujos del MCP, el UCP y los flujos controlados por el agente. Por lo general, no se recomienda para todas las integraciones nuevas.

• Proporcionar seguridad mejorada con el flujo de código de autorización de vinculación de OAuth.

• Permitir que los usuarios existentes accedan a tu plataforma o que los usuarios nuevos verificados por Google se registren en ella, obtener su consentimiento y compartir datos de forma segura con la vinculación optimizada.

• Reducir la fricción con el Cambio de app. Desde una app de Google de confianza, un toque abre de forma segura tu app verificada para Android o iOS, y un toque otorga el consentimiento del usuario y vincula las cuentas

• Mejorar la privacidad del usuario definiendo permisos personalizados para compartir solo los datos necesarios y aumentar la confianza del usuario definiendo claramente cómo se usan sus datos

• Se puede revocar el acceso a los datos y los servicios alojados en tu plataforma desvinculando las cuentas. La implementación de un extremo de revocación de tokens opcional te permite mantenerte sincronizado con los eventos iniciados por Google, mientras que la Protección de cuentas cruzadas (RISC) te permite notificar a Google sobre cualquier evento de desvinculación que tenga lugar en tu plataforma.

Nota: La mayor parte de la documentación de OAuth 2.0 para Google Identity Platform abarca cómo puedes permitir que tus usuarios accedan con sus Cuentas de Google y obtener autorización para llamar a las APIs de Google en su nombre. La vinculación de cuentas de Google abarca el caso inverso de permitir que el usuario de un servicio de Google se autentique con tu plataforma y llame a las APIs de tu servicio. Si deseas usar OAuth 2.0 para acceder a las APIs de Google, consulta la documentación del cliente de OAuth 2.0.

Flujos de vinculación de cuentas

Existen 3 flujos de vinculación de cuentas de Google, todos basados en OAuth, que requieren que administres o controles los extremos de autorización y de intercambio de tokens compatibles con OAuth 2.0.

Durante el proceso de vinculación, emites tokens de acceso a Google para Cuentas de Google individuales después de obtener el consentimiento de los titulares de las cuentas para vincularlas y compartir datos.

Vinculación de OAuth ("OAuth web")

Este es el flujo básico de OAuth que envía a los usuarios a tu sitio web para la vinculación. Se redirecciona al usuario a tu sitio web para que acceda a su cuenta. Una vez que accede, el usuario da su consentimiento para compartir sus datos en tu servicio con Google. En ese momento, se vinculan la Cuenta de Google del usuario y tu servicio.

La vinculación de OAuth admite los flujos de OAuth implícito y de código de autorización. Tu servicio debe alojar un extremo de autorización compatible con OAuth 2.0 para el flujo implícito y debe exponer un extremo de autorización y de intercambio de tokens cuando se usa el flujo de código de autorización.

Precaución: Para los flujos del MCP, el UCP y los flujos controlados por el agente, OAuth 2.1 es obligatorio, y el flujo implícito no es compatible. En su lugar, usa el flujo de código de autorización.

Nota: La implementación de OAuth web es obligatoria para todas las integraciones de vinculación de cuentas, ya que es el método de resguardo para los flujos optimizados y de Cambio de app.

Figura 1. Vinculación de cuentas en el teléfono de un usuario con OAuth web

Vinculación de Cambio de app basada en OAuth ("Cambio de app")

Un flujo de OAuth que envía a los usuarios a tu app para la vinculación.

La vinculación de Cambio de app basada en OAuth guía a los usuarios a medida que se mueven entre tus apps para dispositivos móviles verificadas para Android o iOS y la plataforma de Google para revisar los cambios propuestos en el acceso a los datos y otorgar su consentimiento para vincular su cuenta en tu plataforma con su Cuenta de Google. Para habilitar el Cambio de app, tu servicio debe admitir la vinculación de OAuth o la vinculación de Acceder con Google basada en OAuth con el flujo de código de autorización.

El Cambio de app es compatible con Android y iOS.

Cómo funciona:

La app de Google verifica si tu app está instalada en el dispositivo del usuario:

• Si se encuentra la app, el usuario se "cambia" a tu app. Tu app obtiene el consentimiento del usuario para vincular la cuenta con Google y, luego, "vuelve" a la plataforma de Google.
• Si no se encuentra la app o se produce un error durante el proceso de vinculación de Cambio de app, se redirecciona al usuario al flujo optimizado o de OAuth web.

Figura 2. Vinculación de cuentas en el teléfono de un usuario con Cambio de app

Vinculación optimizada basada en OAuth ("Optimizado")

La vinculación optimizada de Acceder con Google basada en OAuth agrega Acceder con Google sobre la vinculación de OAuth, lo que permite a los usuarios completar el proceso de vinculación sin salir de la plataforma de Google, lo que reduce las fricciones y las bajas. La vinculación optimizada basada en OAuth ofrece la mejor experiencia del usuario con el acceso, la creación de cuentas y la vinculación de cuentas fluidos combinando Acceder con Google con la vinculación de OAuth. Tu servicio debe admitir los extremos de autorización y de intercambio de tokens compatibles con OAuth 2.0. Además, tu extremo de intercambio de tokens debe admitir las aserciones de tokens web JSON (JWT) y debe implementar los intents check, create, y get, .

Nota: El usuario nunca abandona la plataforma de Google durante este flujo, por lo que Google debe mostrar el consentimiento en nombre del tercero para que el flujo funcione correctamente.

Cómo funciona:

Google afirma la cuenta de usuario y te pasa esta información:

• Si existe una cuenta para el usuario en tu base de datos, el usuario vincula correctamente su Cuenta de Google con su cuenta en tu servicio.
• Si no existe una cuenta para el usuario en tu base de datos, el usuario puede crear una cuenta nueva de terceros con la información afirmada que proporciona Google : correo electrónico, nombre y foto de perfil, o elegir acceder y vincularse con otro correo electrónico (esto requerirá que acceda a tu servicio con OAuth web).

Figura 3. Vinculación de cuentas en el teléfono de un usuario con la vinculación optimizada

¿Qué flujo deberías usar?

Te recomendamos que implementes todos los flujos para garantizar que los usuarios obtengan la mejor experiencia de vinculación. Los flujos optimizados y de Cambio de app reducen la fricción de la vinculación, ya que los usuarios pueden completar el proceso de vinculación en muy pocos pasos. La vinculación de OAuth web tiene el nivel de esfuerzo más bajo y es un buen punto de partida después del cual puedes agregar los otros flujos de vinculación.

Nota: El flujo de OAuth web es obligatorio para todas las integraciones, ya que es el resguardo para los otros flujos.

Trabajar con tokens

La vinculación de cuentas de Google se basa en el estándar de la industria de OAuth 2.0.

Emite tokens de acceso a Google para Cuentas de Google individuales después de obtener el consentimiento de los titulares de las cuentas para vincularlas y compartir datos.

Token types

OAuth 2.0 uses strings called tokens to communicate between the user agent, the client application, and the OAuth 2.0 server.

Three types of OAuth 2.0 tokens can be used during account linking:

• Authorization code. A short-lived token that can be exchanged for an access and a refresh token. For security purposes, Google calls your authorization endpoint to obtain a single use or very short-lived code.

• Access token. A token that grants the bearer access to a resource. To limit exposure that could result from the loss of this token, it has a limited lifetime, usually expiring after an hour or so.

• Refresh token. A long-lived token that can be exchanged for a new access token when an access token expires. When your service integrates with Google, this token is exclusively stored and used by Google. Google calls your token exchange endpoint to exchange refresh tokens for access tokens, which are in turn used to access user data.

Token handling

Race conditions in clustered environments and client-server exchanges can result in complex timing and error handling scenarios when working with tokens. For example:

• You receive a request for a new access token, and you issue a new access token. Concurrently, you receive a request for access to your service's resource using the previous, unexpired access token.
• Your refresh token reply is yet to be received (or is never received) by Google. Meanwhile, the previously valid refresh token is used in a request from Google.

Requests and replies can arrive in any order, or not at all due to asynchronous services running in a cluster, network behavior, or other means.

Immediate and fully consistent shared state both within, and between, your and Google's token handling systems cannot be guaranteed. Multiple valid, unexpired tokens can coexist within or across systems short period of time. To minimize negative user impact we recommend you do the following:

• Accept unexpired access tokens, even after a newer token is issued.
• Use alternatives to Refresh Token Rotation.
• Support multiple, concurrently valid access and refresh tokens. For security, you should limit the number of tokens and token lifetime.

Maintenance and outage handling

During maintenance or unplanned outages Google might be unable to call your authorization or token exchange endpoints to obtain access and refresh tokens.

Your endpoints should respond with a 503 error code and empty body. In this case, Google retries failed token exchange requests for a limited time. Provided that Google is later able to obtain refresh and access tokens, failed requests are not visible to users.

Warning: Do not return a 400 error code and {"error": "invalid_grant"} body during maintenance or outages. Doing so deletes previously issued tokens and requires users to relink their accounts.

Failing requests for an access token result in a visible error, if initiated by a user. Users will be required to retry linking failures if the implicit OAuth 2.0 flow is used.

Recommendations

There are many solutions to minimize maintenance impact. Some options to consider:

• Maintain your existing service and route a limited number of requests to your newly updated service. Migrate all requests only after confirming expected functionality.

• Reduce the number of token requests during the maintenance period:

  • Limit maintenance periods to less than the access token lifetime.

  • Temporarily increase the access token lifetime:

    1. Increase token lifetime to greater than maintenance period.
    2. Wait twice the duration of your access token lifetime, enabling users to exchange short lived tokens for longer duration tokens.
    3. Enter maintenance.
    4. Respond to token requests with a 503 error code and empty body.
    5. Exit maintenance.
    6. Decrease token lifetime back to normal.

Registrarse en Google

Necesitaremos detalles de tu configuración de OAuth 2.0 y compartir credenciales para habilitar la vinculación de cuentas. Consulta el registro para obtener más detalles.