Se usó la API de Cloud Translation para traducir esta página.

Vinculación de Cuentas de Google con OAuth

Las cuentas se vinculan con los flujos implícitos y de código de autorización de OAuth 2.0 estándar de la industria. Tu servicio debe admitir extremos de autorización y de intercambio de tokens que cumplan con OAuth 2.0.

En el flujo implícito, Google abre el extremo de autorización en el navegador del usuario. Después de acceder correctamente, devuelves un token de acceso de larga duración a Google. Este token de acceso ahora se incluye en cada solicitud que se envía desde Google.

En el flujo de código de autorización, necesitas dos extremos:

El extremo de autorización, que presenta la IU de acceso a los usuarios que aún no accedieron El extremo de autorización también crea un código de autorización de corta duración para registrar el consentimiento de los usuarios para el acceso solicitado.
El extremo de intercambio de tokens, que 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 un token de acceso de corta duración. Este intercambio se produce 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 token de acceso de corta duración. Este intercambio se produce cuando Google necesita un nuevo token de acceso porque venció.

Elige un flujo de OAuth 2.0

Si bien el flujo implícito es más fácil de implementar, Google recomienda que los tokens de acceso emitidos por el flujo implícito nunca venzan. Esto se debe a que el usuario se ve obligado a volver a vincular su cuenta después de que vence un token con el flujo implícito. Si necesitas que el token venza por motivos de seguridad, te recomendamos que uses el flujo de código de autorización en su lugar.

Lineamientos de diseño

En esta sección, se describen los requisitos y las recomendaciones de diseño para la pantalla del usuario que alojas para los flujos de vinculación de OAuth. Después de que la app de Google le hace una llamada, tu plataforma le muestra al usuario una página de acceso a Google y una pantalla de consentimiento para la vinculación de cuentas. Se redirecciona al usuario a la app de Google después de que da su consentimiento para vincular las cuentas.

En esta figura, se muestran los pasos para que un usuario vincule su Cuenta de Google a tu sistema de autenticación. En la primera captura de pantalla, se muestra la vinculación que inicia el usuario desde tu plataforma. La segunda imagen muestra el acceso del usuario a Google, mientras que la tercera muestra el consentimiento y la confirmación del usuario para vincular su Cuenta de Google con tu app. La captura de pantalla final muestra una cuenta de usuario vinculada correctamente en la app de Google. — **Figura 1.** Acceso del usuario a la vinculación de cuentas con Google y pantallas de consentimiento

Requisitos

Debes comunicar que la cuenta del usuario se vinculará a Google, no a un producto específico de Google, como Google Home o Asistente de Google.

Recomendaciones

Crea el proyecto

Para crear tu proyecto y usar la vinculación de cuentas, haz lo siguiente:

Haz clic en Crear proyecto.
Ingresa un nombre o acepta la sugerencia generada.
Confirma o edita los campos restantes.
Haz clic en Crear.

Para ver el ID de tu proyecto, haz lo siguiente:

Busca tu proyecto en la tabla de la página de destino. El ID del proyecto aparece en la columna ID.

Configura tu pantalla de consentimiento de OAuth

El proceso de vinculación de la Cuenta de Google incluye una pantalla de consentimiento que les indica a los usuarios la aplicación que solicita acceso a sus datos, qué tipo de datos solicita y las condiciones que se aplican. Deberás configurar tu pantalla de consentimiento de OAuth antes de generar un ID de cliente de la API de Google.

Abre la página Pantalla de consentimiento de OAuth de la consola de APIs de Google.
Si se te solicita, selecciona el proyecto que acabas de crear.
En la página "Pantalla de consentimiento de OAuth", completa el formulario y haz clic en el botón "Guardar".

Nombre de la aplicación: Es el nombre de la aplicación que solicita el consentimiento. El nombre debe reflejar con precisión tu aplicación y ser coherente con el nombre de la aplicación que los usuarios ven en otros lugares. El nombre de la aplicación se mostrará en la pantalla de consentimiento de la vinculación de la cuenta.

Logotipo de la aplicación: Es una imagen en la pantalla de consentimiento que ayudará a los usuarios a reconocer tu app. El logotipo se muestra en la pantalla de consentimiento de vinculación de cuentas y en la configuración de la cuenta.

Correo electrónico de asistencia: Para que los usuarios se comuniquen contigo si tienen preguntas sobre su consentimiento.

Permisos para las APIs de Google: Los permisos permiten que tu aplicación acceda a los datos privados de Google de tus usuarios. En el caso de uso de la vinculación de la Cuenta de Google, el alcance predeterminado (correo electrónico, perfil, openid) es suficiente, por lo que no es necesario agregar alcances sensibles. Por lo general, se recomienda solicitar permisos de forma incremental, en el momento en que se requiere el acceso, en lugar de hacerlo por adelantado. Obtén más información.

Dominios autorizados: Para protegerte a ti y a tus usuarios, Google solo permite que las aplicaciones que se autentican con OAuth usen dominios autorizados. Los vínculos de tus aplicaciones deben alojarse en dominios autorizados. Obtén más información.

Vínculo a la página principal de la aplicación: Es la página principal de tu aplicación. Debe estar alojado en un dominio autorizado.

Vínculo a la Política de Privacidad de la aplicación: Se muestra en la pantalla de consentimiento de la vinculación de la Cuenta de Google. Debe estar alojado en un dominio autorizado.

Vínculo a las Condiciones del Servicio de la aplicación (opcional): Debe estar alojado en un dominio autorizado.

Figura 1. Pantalla de consentimiento de vinculación de la Cuenta de Google para una aplicación ficticia, Tunery
Verifica el "Estado de verificación". Si tu aplicación necesita verificación, haz clic en el botón "Enviar para verificación" para enviar tu aplicación a verificación. Consulta los requisitos de verificación de OAuth para obtener más detalles.

Implementa tu servidor de OAuth

To support the OAuth 2.0 implicit flow, your service makes an authorization endpoint available by HTTPS. This endpoint is responsible for authentication and obtaining consent from users for data access. The authorization endpoint presents a sign-in UI to your users that aren't already signed in and records consent to the requested access.

When a Google application needs to call one of your service's authorized APIs, Google uses this endpoint to get permission from your users to call these APIs on their behalf.

A typical OAuth 2.0 implicit flow session initiated by Google has the following flow:

Google opens your authorization endpoint in the user's browser. The user signs in, if not signed in already, and grants Google permission to access their data with your API, if they haven't already granted permission.
Your service creates an access token and returns it to Google. To do so, redirect the user's browser back to Google with the access token attached to the request.
Google calls your service's APIs and attaches the access token with each request. Your service verifies that the access token grants Google authorization to access the API and then completes the API call.

Handle authorization requests

When a Google application needs to perform account linking via an OAuth 2.0 implicit flow, Google sends the user to your authorization endpoint with a request that includes the following parameters:

Authorization endpoint parameters
`client_id`	The client ID you assigned to Google.
`redirect_uri`	The URL to which you send the response to this request.
`state`	A bookkeeping value that is passed back to Google unchanged in the redirect URI.
`response_type`	The type of value to return in the response. For the OAuth 2.0 implicit flow, the response type is always `token`.
`user_locale`	The Google Account language setting in RFC5646 format used to localize your content in the user's preferred language.

For example, if your authorization endpoint is available at https://myservice.example.com/auth, a request might look like the following:

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&response_type=token&user_locale=LOCALE

For your authorization endpoint to handle sign-in requests, do the following steps:

Verify the client_id and redirect_uri values to prevent granting access to unintended or misconfigured client apps:
- Confirm that the client_id matches the client ID you assigned to Google.
- Confirm that the URL specified by the redirect_uri parameter has the following form:
```
https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
```
Check if the user is signed in to your service. If the user isn't signed in, complete your service's sign-in or sign-up flow.
Generate an access token for Google to use to access your API. The access token can be any string value, but it must uniquely represent the user and the client the token is for and must not be guessable.
Send an HTTP response that redirects the user's browser to the URL specified by the redirect_uri parameter. Include all of the following parameters in the URL fragment:
- access_token: The access token you just generated
- token_type: The string bearer
- state: The unmodified state value from the original request
The following is an example of the resulting URL:
```
https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID#access_token=ACCESS_TOKEN&token_type=bearer&state=STATE_STRING
```

Google's OAuth 2.0 redirect handler receives the access token and confirms that the state value hasn't changed. After Google has obtained an access token for your service, Google attaches the token to subsequent calls to your service APIs.

Handle userinfo requests

The userinfo endpoint is an OAuth 2.0 protected resource that return claims about the linked user. Implementing and hosting the userinfo endpoint is optional, except for the following use cases:

Linked Account Sign-In with Google One Tap.
Frictionless subscription on AndroidTV.

After the access token has been successfully retrieved from your token endpoint, Google sends a request to your userinfo endpoint to retrieve basic profile information about the linked user.

userinfo endpoint request headers
`Authorization header`	The access token of type Bearer.

For example, if your userinfo endpoint is available at https://myservice.example.com/userinfo, a request might look like the following:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

For your userinfo endpoint to handle requests, do the following steps:

Extract access token from the Authorization header and return information for the user associated with the access token.
If the access token is invalid, return an HTTP 401 Unauthorized error with using the WWW-Authenticate Response Header. Below is an example of a userinfo error response:
```
HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="The Access Token expired"
```
If a 401 Unauthorized, or any other unsuccessful error response is returned during the linking process, the error will be non-recoverable, the retrieved token will be discarded and the user will have to initiate the linking process again.

If the access token is valid, return and HTTP 200 response with the following JSON object in the body of the HTTPS response:

{
"sub": "USER_UUID",
"email": "EMAIL_ADDRESS",
"given_name": "FIRST_NAME",
"family_name": "LAST_NAME",
"name": "FULL_NAME",
"picture": "PROFILE_PICTURE",
}

If your userinfo endpoint returns an HTTP 200 success response, the retrieved token and claims are registered against the user's Google account.

userinfo endpoint response
`sub`	A unique ID that identifies the user in your system.
`email`	Email address of the user.
`given_name`	Optional: First name of the user.
`family_name`	Optional: Last name of the user.
`name`	Optional: Full name of the user.
`picture`	Optional: Profile picture of the user.

Cómo validar la implementación

Puedes validar tu implementación con la herramienta OAuth 2.0 Playground.

En la herramienta, sigue estos pasos:

Haz clic en Configuración para abrir la ventana de configuración de OAuth 2.0.
En el campo Flujo de OAuth, selecciona Del cliente.
En el campo Extremos de OAuth, selecciona Personalizado.
Especifica tu extremo de OAuth 2.0 y el ID de cliente que le asignaste a Google en los campos correspondientes.
En la sección Paso 1, no selecciones ningún alcance de Google. En su lugar, deja este campo en blanco o escribe un alcance válido para tu servidor (o una cadena arbitraria si no usas permisos de OAuth). Cuando termines, haz clic en Autorizar APIs.
En las secciones Paso 2 y Paso 3, revisa el flujo de OAuth 2.0 y verifica que cada paso funcione según lo previsto.

Puedes validar tu implementación con la herramienta de demostración de vinculación de Cuentas de Google.