Vinculación de Cuentas de Google con OAuth (flujo implícito; archivado)

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 acceder 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 endpoint para obtener permiso de tus usuarios para llamar a estas APIs en su nombre.

Vinculación de la Cuenta 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 los roles y las responsabilidades de los actores en el flujo implícito de OAuth de la vinculación de la Cuenta 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 servicio.

Una sesión típica del flujo implícito de OAuth 2.0 iniciada por Google tiene el siguiente flujo:

1. 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.
2. Tu servicio crea un token de acceso y se lo devuelve a Google. Para ello, redirecciona el navegador del usuario a Google con el token de acceso adjunto a la solicitud.
3. 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 otorgue autorización a Google para acceder a la API y, luego, completa la llamada a la API.

Receta de implementación

Sigue estos pasos para implementar el flujo implícito.

Paso 1: Controla las solicitudes de autorización

Cuando Google inicia la vinculación de la cuenta, redirecciona al usuario a tu extremo de autorización. Para obtener información detallada sobre los contratos de protocolo y los requisitos de parámetros, consulta el extremo de autorización.

Para controlar la solicitud, realiza las siguientes acciones:

1. Valida la solicitud:

   • Confirma que el valor de client_id coincida con el ID de cliente asignado a Google.
   • Confirma que redirect_uri coincida con la URL de redireccionamiento de Google esperada: none https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
   • Verifica que response_type sea token.

2. Autentica al usuario:

   • Verifica si el usuario accedió a tu servicio.
   • Si el usuario no accedió, pídele que complete tu flujo de acceso o registro.

3. Genera un token de acceso:

   • Crea un token de acceso único y no adivinable asociado con el usuario y el cliente.

4. Redirige a Google:

   • Redirecciona el navegador a la URL proporcionada en redirect_uri.
   • Agrega los siguientes parámetros al fragmento de URL (hash):
     • access_token: Es el token de acceso que generaste.
     • token_type: Debe ser bearer.
     • state: Es el valor de estado sin modificar que se recibió de Google.

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.

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:

1. Extract access token from the Authorization header and return information for the user associated with the access token.
2. 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.

3. 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.