Las cuentas se vinculan con los flujos implícito y de código de autorización de OAuth 2.0, que son estándares de la industria.
Tu servicio debe admitir extremos de autorización y de intercambio de tokens que cumplan con OAuth 2.0.
In the implicit flow, Google opens your authorization endpoint in the user's browser. After successful sign in, you return a long-lived access token to Google. This access token is now included in every request sent from Google.
In the authorization code flow, you need two endpoints:
The authorization endpoint, which presents the sign-in UI to your users that aren't already signed in. The authorization endpoint also creates a short-lived authorization code to record users' consent to the requested access.
The token exchange endpoint, which is responsible for two types of exchanges:
- Exchanges an authorization code for a long-lived refresh token and a short-lived access token. This exchange happens when the user goes through the account linking flow.
- Exchanges a long-lived refresh token for a short-lived access token. This exchange happens when Google needs a new access token because the one it had expired.
Choose an OAuth 2.0 flow
Although the implicit flow is simpler to implement, Google recommends that access tokens issued by the implicit flow never expire. This is because the user is forced to link their account again after a token expires with the implicit flow. If you need token expiration for security reasons, we strongly recommend that you use the authorization code flow instead.
Design guidelines
This section describes the design requirements and recommendations for the user screen that you host for OAuth linking flows. After it's called by Google's app, your platform displays a sign in to Google page and account linking consent screen to the user. The user is directed back to Google's app after giving their consent to link accounts.
Requirements
- You must communicate that the user's account will be linked to Google, not a specific Google product like Google Home or Google Assistant.
Recommendations
We recommend that you do the following:
Display Google's Privacy Policy. Include a link to Google's Privacy Policy on the consent screen.
Data to be shared. Use clear and concise language to tell the user what data of theirs Google requires and why.
Clear call-to-action. State a clear call-to-action on your consent screen, such as "Agree and link." This is because users need to understand what data they're required to share with Google to link their accounts.
Ability to cancel. Provide a way for users to go back or cancel, if they choose not to link.
Clear sign-in process. Ensure that users have clear method for signing in to their Google Account, such as fields for their username and password or Sign in with Google.
Ability to unlink. Offer a mechanism for users to unlink, such as a URL to their account settings on your platform. Alternatively, you can include a link to Google Account where users can manage their linked account.
Ability to change user account. Suggest a method for users to switch their account(s). This is especially beneficial if users tend to have multiple accounts.
- If a user must close the consent screen to switch accounts, send a recoverable error to Google so the user can sign in to the selected account with OAuth linking and the implicit flow.
Include your logo. Display your company logo on the consent screen. Use your style guidelines to place your logo. If you want or need to also display Google's logo, see Logos and trademarks.
Crea el proyecto
Para crear tu proyecto y usar la vinculación de cuentas, haz lo siguiente:
- Ve a la Consola de API de Google.
- 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 del proyecto, haz lo siguiente:
- Ve a la Consola de API de Google.
- Busca tu proyecto en la tabla de la página de destino. El ID del proyecto aparece en la ID columna.
Configura la pantalla de consentimiento de OAuth
El proceso de vinculación de Cuentas 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 la pantalla de consentimiento de OAuth antes de generar un ID de cliente de la API de Google.
- Abre la página de la 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 vinculación de cuentas.
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: Es 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 tu usuario. Para el caso de uso de vinculación de Cuentas de Google, el permiso predeterminado (correo electrónico, perfil, openid) es suficiente, no es necesario agregar permisos 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 protegerlos 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 alojarse en un dominio autorizado.
Vínculo a la Política de Privacidad de la aplicación: Se muestra en la pantalla de consentimiento de vinculación de Cuentas de Google. Debe alojarse en un dominio autorizado.
Vínculo a las Condiciones del Servicio de la aplicación (opcional): Debe alojarse en un dominio autorizado.
Figura 1. Pantalla de consentimiento de vinculación de Cuentas 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 enviarla. Consulta los requisitos de verificación de OAuth para obtener más detalles.
Implementa tu servidor de OAuth
n
Para admitir el flujo implícito de OAuth 2.0, tu servicio pone a disposición un extremo de autorización a través de HTTPS. Este extremo es responsable de la autenticación y de obtener el consentimiento de los usuarios para el acceso a los datos. El extremo de autorización presenta una IU de acceso a los usuarios que aún no accedieron y registra el consentimiento para el acceso solicitado.
Cuando una aplicación de Google necesita llamar a una de las APIs autorizadas de tu servicio, Google usa este extremo para obtener permiso de tus usuarios para llamar a estas APIs en su nombre.
Vinculación de Cuentas de Google: Flujo implícito de OAuth
En el siguiente diagrama de secuencia, se detallan las interacciones entre el usuario, Google y los extremos de tu servicio.
Funciones y responsabilidades
En la siguiente tabla, se definen las funciones y responsabilidades de los actores en el flujo implícito de OAuth de la vinculación de Cuentas de Google (GAL). Ten en cuenta que, en GAL, Google actúa como el cliente de OAuth , mientras que tu servicio actúa como el proveedor de identidad o de servicios.
| Actor o componente | Función de GAL | Responsabilidades |
|---|---|---|
| App o servidor de Google | Cliente de OAuth | Inicia el flujo, recibe el token de acceso mediante un redireccionamiento del navegador, y lo almacena de forma segura para acceder a las APIs de tu servicio. |
| Tu extremo de autorización | Servidor de autorización | Autentica a tus usuarios, obtiene su consentimiento y emite tokens de acceso de larga duración a Google. |
| URI de redireccionamiento de Google | Extremo de devolución de llamada | Recibe el redireccionamiento del usuario desde tu servicio de autorización con los valores
access_token y state en el fragmento de la URL. |
Una sesión típica del flujo implícito de OAuth 2.0 iniciada por Google tiene el siguiente flujo:
- Google abre tu extremo de autorización en el navegador del usuario. El usuario accede, si aún no lo hizo, y le otorga permiso a Google para acceder a sus datos con tu API, si aún no lo hizo.
- Tu servicio crea un token de acceso y lo devuelve a Google. Para ello, redirecciona el navegador del usuario a Google con el token de acceso adjunto a la solicitud.
- Google llama a las APIs de tu servicio y adjunta el token de acceso con cada solicitud. Tu servicio verifica que el token de acceso le otorgue a Google autorización para acceder a la API y, luego, completa la llamada a la API.
Cómo controlar las solicitudes de autorización
Cuando una aplicación de Google necesita realizar la vinculación de cuentas con un flujo implícito de OAuth 2.0, Google envía al usuario a tu extremo de autorización con una solicitud que incluye los siguientes parámetros:
| Parámetros del extremo de autorización | |
|---|---|
client_id |
Es el ID de cliente que le asignaste a Google. |
redirect_uri |
Es la URL a la que envías la respuesta de esta solicitud. |
state |
Es un valor de contabilidad que se pasa a Google sin cambios en el URI de redireccionamiento. |
response_type |
Es el tipo de valor que se mostrará en la respuesta. Para el flujo implícito de OAuth 2.0
el tipo de respuesta siempre es token. |
user_locale |
Es la configuración de idioma de la Cuenta de Google en RFC5646 formato que se usa para localizar tu contenido en el idioma preferido del usuario. |
Por ejemplo, si tu extremo de autorización está disponible en https://myservice.example.com/auth, una solicitud podría verse de la siguiente manera:
GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&response_type=token&user_locale=LOCALE
Para que tu extremo de autorización controle las solicitudes de acceso, sigue estos pasos:
Verifica los valores
client_idyredirect_uripara evitar otorgar acceso a apps cliente no deseadas o mal configuradas:- Confirma que el
client_idcoincida con el ID de cliente que le asignaste a Google. - Confirma que la URL especificada por el parámetro
redirect_uritenga el siguiente formato:https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
- Confirma que el
Verifica si el usuario accedió a tu servicio. Si el usuario no accedió, completa el flujo de acceso o registro de tu servicio.
Genera un token de acceso para que Google lo use para acceder a tu API. El token de acceso puede ser cualquier valor de cadena, pero debe representar de forma única al usuario y al cliente para el que es el token, y no debe ser adivinable.
Envía una respuesta HTTP que redireccione el navegador del usuario a la URL especificada por el
redirect_uriparámetro. Incluye todos los siguientes parámetros en el fragmento de la URL:access_token: Es el token de acceso que acabas de generar.token_type: Es la cadenabearer.state: Es el valor de estado sin modificar de la solicitud original.
El siguiente es un ejemplo de la URL resultante:
https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID#access_token=ACCESS_TOKEN&token_type=bearer&state=STATE_STRING
El controlador de redireccionamiento de OAuth 2.0 de Google recibe el token de acceso y confirma que el valor state no cambió. Después de que Google obtiene un token de acceso para tu servicio, lo adjunta a las llamadas posteriores a las APIs de tu servicio.
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-AuthenticateResponse Header. Below is an example of a userinfo error response: 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.HTTP/1.1 401 Unauthorized WWW-Authenticate: error="invalid_token", error_description="The Access Token expired"
If the access token is valid, return and HTTP 200 response with the following JSON object in the body of the HTTPS response:
If your userinfo endpoint returns an HTTP 200 success response, the retrieved token and claims are registered against the user's Google account.{ "sub": "USER_UUID", "email": "EMAIL_ADDRESS", "given_name": "FIRST_NAME", "family_name": "LAST_NAME", "name": "FULL_NAME", "picture": "PROFILE_PICTURE", }userinfo endpoint response subA unique ID that identifies the user in your system. emailEmail address of the user. given_nameOptional: First name of the user. family_nameOptional: Last name of the user. nameOptional: Full name of the user. pictureOptional: 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 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 alcances de OAuth). Cuando termines, haz clic en Autorizar APIs.
- En las secciones Paso 2 y Paso 3, sigue 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.
En la herramienta, sigue estos pasos:
- Haz clic en el botón Acceder con Google.
- Elige la cuenta que quieras vincular.
- Ingresa el ID de servicio.
- De manera opcional, ingresa uno o más alcances para los que solicitarás acceso.
- Haz clic en Iniciar demostración.
- Cuando se te solicite, confirma que puedes dar tu consentimiento y rechazar la solicitud de vinculación.
- Confirma que se te redirecciona a tu plataforma.