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

Vinculación optimizada con OAuth y el inicio de sesión de Google

Descripción general

Basada en OAuth vinculación de sesión de Google optimizada añade acceso de Google en la parte superior de OAuth vinculación . Esto proporciona una experiencia de vinculación perfecta para los usuarios de Google y también permite la creación de cuentas, lo que permite al usuario crear una nueva cuenta en su servicio utilizando su cuenta de Google.

Para realizar la vinculación de cuentas con OAuth y Google Sign-In, siga estos pasos generales:

En primer lugar, pide al usuario que dé su consentimiento para acceder a su perfil de Google.
Utilice la información de su perfil para comprobar si existe la cuenta de usuario.
Para los usuarios existentes, vincule las cuentas.
Si no puede encontrar una coincidencia para el usuario de Google en su sistema de autenticación, valide el token de identificación recibido de Google. Luego puede crear un usuario basado en la información de perfil contenida en el token de ID.

Esta figura muestra los pasos para que un usuario vincule su cuenta de Google mediante el flujo de vinculación simplificado. La primera captura de pantalla muestra cómo un usuario puede seleccionar su aplicación para vincularla. La segunda captura de pantalla le permite al usuario confirmar si tiene o no una cuenta existente en su servicio. La tercera captura de pantalla le permite al usuario seleccionar la cuenta de Google con la que desea vincularse. La cuarta captura de pantalla muestra la confirmación de vincular su cuenta de Google con su aplicación. La quinta captura de pantalla muestra una cuenta de usuario vinculada con éxito en la aplicación de Google.

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

Requisitos para la vinculación optimizada

Implementar la vinculación básica de OAuth web . Su servicio debe admitir la autorización OAuth 2.0 compatible con los puntos finales y de cambio de fichas.
Su punto final Cambio de Ficha debe ser compatible con JSON Web Token (JWT) afirmaciones e implementar el check , create y get intenciones.

Registrar su ID de Google API de cliente .

Implementa tu servidor OAuth

Su punto final Cambio de Ficha debe ser compatible con el check , create , get intenciones. A continuación, se muestran los pasos completados a través del flujo de vinculación de cuentas e indica cuándo se llaman las diferentes intenciones:

¿El usuario tiene una cuenta en su sistema de autenticación? (El usuario decide seleccionando SI o NO)
1. SÍ: ¿El usuario utiliza el correo electrónico asociado a su cuenta de Google para iniciar sesión en su plataforma? (El usuario decide seleccionando SI o NO)
  1. SÍ: ¿Tiene el usuario una cuenta coincidente en su sistema de autenticación? ( check intent está llamado a confirmar)
    1. SÍ: get intent que se llama y la cuenta está vinculada si la intención obtener retornos con éxito.
    2. NO: ¿Crear nueva cuenta? (El usuario decide seleccionando SI o NO)
      1. SÍ: create intent que se llama y la cuenta está vinculada si la intención de crear rendimientos éxito.
      2. NO: se activa el flujo de Web OAuth, se dirige al usuario a su navegador y se le da la opción de vincularse con un correo electrónico diferente.
  2. NO: El flujo de OAuth Web se activa, el usuario es dirigido a su navegador, y el usuario tiene la opción de enlace con un correo electrónico diferente.
2. NO: ¿Tiene el usuario una cuenta coincidente en su sistema de autenticación? ( check intent está llamado a confirmar)
  1. SÍ: get intent que se llama y la cuenta está vinculada si la intención obtener retornos con éxito.
  2. Nº: create intent que se llama y la cuenta está vinculada si la intención de crear rendimientos éxito.

Check for an existing user account (check intent)

After the user gives consent to access their Google profile, Google sends a request that contains a signed assertion of the Google user's identity. The assertion contains information that includes the user's Google Account ID, name, and email address. The token exchange endpoint configured for your project handles that request.

If the corresponding Google account is already present in your authentication system, your token exchange endpoint responds with account_found=true. If the Google account doesn't match an existing user, your token exchange endpoint returns an HTTP 404 Not Found error with account_found=false.

The request has the following form:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&intent=check&assertion=JWT&scope=SCOPES

Your token exchange endpoint must be able to handle the following parameters:

Token endpoint parameters
`intent`	For these requests, the value of this parameter is `check`.
`grant_type`	The type of token being exchanged. For these requests, this parameter has the value `urn:ietf:params:oauth:grant-type:jwt-bearer`.
`assertion`	A JSON Web Token (JWT) that provides a signed assertion of the Google user's identity. The JWT contains information that includes the user's Google Account ID, name, and email address.

To respond to the check intent requests, your token exchange endpoint must perform the following steps:

Validate and decode the JWT assertion.
Check if the Google account is already present in your authentication system.

Validar y decodificar la aserción JWT

Puede validar y decodificar la aserción JWT utilizando una biblioteca de decodificación JWT para su idioma . Utilice las claves públicas de Google, disponibles en formatos JWK o PEM , para verificar la firma del token.

Cuando se decodifica, la aserción JWT se parece al siguiente ejemplo:

{
  "sub": "1234567890",      // The unique ID of the user's Google Account
  "iss": "https://accounts.google.com",        // The assertion's issuer
  "aud": "123-abc.apps.googleusercontent.com", // Your server's client ID
  "iat": 233366400,         // Unix timestamp of the assertion's creation time
  "exp": 233370000,         // Unix timestamp of the assertion's expiration time
  "name": "Jan Jansen",
  "given_name": "Jan",
  "family_name": "Jansen",
  "email": "jan@gmail.com", // If present, the user's email address
  "email_verified": true,   // true, if Google has verified the email address
  "hd": "example.com",      // If present, the host domain of the user's GSuite email address
                            // If present, a URL to user's profile picture
  "picture": "https://lh3.googleusercontent.com/a-/AOh14GjlTnZKHAeb94A-FmEbwZv7uJD986VOF1mJGb2YYQ",
  "locale": "en_US"         // User's locale, from browser or phone settings
}

Además de verificar la firma del token, verifique que el emisor de la afirmación (campo iss ) sea https://accounts.google.com , que la audiencia (campo aud ) sea su ID de cliente asignado y que el token no haya caducado ( exp campo).

Con los campos email , email_verified y hd puede determinar si Google aloja y tiene autoridad para una dirección de correo electrónico. En los casos en que Google tiene autoridad, se sabe que el usuario es el propietario legítimo de la cuenta y puede omitir la contraseña u otros métodos de desafío. De lo contrario, estos métodos se pueden utilizar para verificar la cuenta antes de vincularla.

Casos en los que Google tiene autoridad:

email tiene un sufijo @gmail.com , esta es una cuenta de Gmail.
email_verified es verdadero y hd está configurado, esta es una cuenta de G Suite.

Los usuarios pueden registrarse para obtener cuentas de Google sin usar Gmail o G Suite. Cuando el email no contiene un sufijo @gmail.com y no hay hd Google no tiene autoridad y se recomienda utilizar una contraseña u otros métodos de desafío para verificar al usuario. email_verfied también puede ser cierto ya que Google verificó inicialmente al usuario cuando se creó la cuenta de Google, sin embargo, la propiedad de la cuenta de correo electrónico de terceros puede haber cambiado desde entonces.

Check if the Google account is already present in your authentication system

Check whether either of the following conditions are true:

The Google Account ID, found in the assertion's sub field, is in your user database.
The email address in the assertion matches a user in your user database.

If either condition is true, the user has already signed up. In that case, return a response like the following:

HTTP/1.1 200 Success
Content-Type: application/json;charset=UTF-8

{
  "account_found":"true",
}

If neither the Google Account ID nor the email address specified in the assertion matches a user in your database, the user hasn't signed up yet. In this case, your token exchange endpoint needs to reply with a HTTP 404 error that specifies "account_found": "false", as in the following example:

HTTP/1.1 404 Not found
Content-Type: application/json;charset=UTF-8

{
  "account_found":"false",
}

Handle automatic linking (get intent)

If the corresponding Google Account is already present in your authentication system, your token exchange endpoint returns a token for the user. If the Google Account doesn't match an existing user, your token exchange endpoint returns a linking_error error and optional login_hint.

The request has the following form:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&intent=get&assertion=JWT&scope=SCOPES

Your token exchange endpoint must be able to handle the following parameters:

Token endpoint parameters
`intent`	For these requests, the value of this parameter is `get`.
`grant_type`	The type of token being exchanged. For these requests, this parameter has the value `urn:ietf:params:oauth:grant-type:jwt-bearer`.
`assertion`	A JSON Web Token (JWT) that provides a signed assertion of the Google user's identity. The JWT contains information that includes the user's Google Account ID, name, and email address.
`scope`	Optional: Any scopes that you've configured Google to request from users.

To respond to the get intent requests, your token exchange endpoint must perform the following steps:

Validate and decode the JWT assertion.
Check if the Google account is already present in your authentication system.

Validar y decodificar la aserción JWT

Cuando se decodifica, la aserción JWT se parece al siguiente ejemplo:

{
  "sub": "1234567890",      // The unique ID of the user's Google Account
  "iss": "https://accounts.google.com",        // The assertion's issuer
  "aud": "123-abc.apps.googleusercontent.com", // Your server's client ID
  "iat": 233366400,         // Unix timestamp of the assertion's creation time
  "exp": 233370000,         // Unix timestamp of the assertion's expiration time
  "name": "Jan Jansen",
  "given_name": "Jan",
  "family_name": "Jansen",
  "email": "jan@gmail.com", // If present, the user's email address
  "email_verified": true,   // true, if Google has verified the email address
  "hd": "example.com",      // If present, the host domain of the user's GSuite email address
                            // If present, a URL to user's profile picture
  "picture": "https://lh3.googleusercontent.com/a-/AOh14GjlTnZKHAeb94A-FmEbwZv7uJD986VOF1mJGb2YYQ",
  "locale": "en_US"         // User's locale, from browser or phone settings
}

Casos en los que Google tiene autoridad:

email tiene un sufijo @gmail.com , esta es una cuenta de Gmail.
email_verified es verdadero y hd está configurado, esta es una cuenta de G Suite.

Check if the Google account is already present in your authentication system

Check whether either of the following conditions are true:

The Google Account ID, found in the assertion's sub field, is in your user database.
The email address in the assertion matches a user in your user database.

If an account is found for the user, issue an access token and return the values in a JSON object in the body of your HTTPS response, like in the following example:

{
  "token_type": "Bearer",
  "access_token": "ACCESS_TOKEN",

  "expires_in": SECONDS_TO_EXPIRATION
}

In some cases, account linking based on ID token might fail for the user. If it does so for any reason, your token exchange endpoint needs to reply with a HTTP 401 error that specifies error=linking_error, as the following example shows:

HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=UTF-8

{
  "error":"linking_error",
  "login_hint":"foo@bar.com"
}

When Google receives a 401 error response with linking_error, Google sends the user to your authorization endpoint with login_hint as a parameter. The user completes account linking using the OAuth linking flow in their browser.

Handle account creation via Google Sign-In (create intent)

When a user needs to create an account on your service, Google makes a request to your token exchange endpoint that specifies intent=create.

The request has the following form:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

response_type=token&grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&scope=SCOPES&intent=create&assertion=JWT

Your token exchange endpoint must able to handle the following parameters:

Token endpoint parameters
`intent`	For these requests, the value of this parameter is `create`.
`grant_type`	The type of token being exchanged. For these requests, this parameter has the value `urn:ietf:params:oauth:grant-type:jwt-bearer`.
`assertion`	A JSON Web Token (JWT) that provides a signed assertion of the Google user's identity. The JWT contains information that includes the user's Google Account ID, name, and email address.

The JWT within the assertion parameter contains the user's Google Account ID, name, and email address, which you can use to create a new account on your service.

To respond to the create intent requests, your token exchange endpoint must perform the following steps:

Validate and decode the JWT assertion.
Validate user information and create new account.

Validar y decodificar la aserción JWT

Cuando se decodifica, la aserción JWT se parece al siguiente ejemplo:

{
  "sub": "1234567890",      // The unique ID of the user's Google Account
  "iss": "https://accounts.google.com",        // The assertion's issuer
  "aud": "123-abc.apps.googleusercontent.com", // Your server's client ID
  "iat": 233366400,         // Unix timestamp of the assertion's creation time
  "exp": 233370000,         // Unix timestamp of the assertion's expiration time
  "name": "Jan Jansen",
  "given_name": "Jan",
  "family_name": "Jansen",
  "email": "jan@gmail.com", // If present, the user's email address
  "email_verified": true,   // true, if Google has verified the email address
  "hd": "example.com",      // If present, the host domain of the user's GSuite email address
                            // If present, a URL to user's profile picture
  "picture": "https://lh3.googleusercontent.com/a-/AOh14GjlTnZKHAeb94A-FmEbwZv7uJD986VOF1mJGb2YYQ",
  "locale": "en_US"         // User's locale, from browser or phone settings
}

Casos en los que Google tiene autoridad:

email tiene un sufijo @gmail.com , esta es una cuenta de Gmail.
email_verified es verdadero y hd está configurado, esta es una cuenta de G Suite.

Validate user information and create new account

Check whether either of the following conditions are true:

The Google Account ID, found in the assertion's sub field, is in your user database.
The email address in the assertion matches a user in your user database.

If either condition is true, prompt the user to link their existing account with their Google Account. To do so, respond to the request with an HTTP 401 error that specifies error=linking_error and gives the user's email address as the login_hint. The following is a sample response:

HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=UTF-8

{
  "error":"linking_error",
  "login_hint":"foo@bar.com"
}

If neither condition is true, create a new user account with the information provided in the JWT. New accounts don't typically have a password set. It's recommended that you add Google Sign-In to other platforms to enable users to log in with Google across the surfaces of your application. Alternatively, you can email the user a link that starts your password recovery flow to allow the user to set a password to sign in on other platforms.

When the creation is completed, issue an access token and return the values in a JSON object in the body of your HTTPS response, like in the following example:

{
  "token_type": "Bearer",
  "access_token": "ACCESS_TOKEN",

  "expires_in": SECONDS_TO_EXPIRATION
}

Obtenga su ID de cliente de la API de Google

Se le pedirá que proporcione su ID de Google API de cliente durante el enlace de cuentas de registro de proceso.

Para obtener su API ID de cliente utilizando el proyecto que ha creado al completar los OAuth Linking pasos. Para hacerlo, complete los siguientes pasos:

Abra la página Credenciales de la consola de API de Google .
Cree o seleccione un proyecto de API de Google.
Si el proyecto no tiene un ID de cliente para el tipo de aplicación Web, haga clic en Crear credenciales> OAuth ID de cliente para crear una. Asegúrese de incluir el dominio de su sitio en el palco de los orígenes de JavaScript autorizados. Al realizar pruebas o desarrollo locales, debe agregar tanto http://localhost y http://localhost:<port_number> al campo orígenes JavaScript autorizado.
Punto Clave: Agregar tanto http://localhost y http://localhost:<port_number> al campo orígenes JavaScript autorizado para pruebas o desarrollo local.
Nota: Un ID de cliente tiene el siguiente ejemplo:
```
1234567890-abc123def456.apps.googleusercontent.com
```

Validando su implementación

您可以通过使用验证实现的OAuth 2.0游乐场工具。

在工具中，执行以下步骤：

单击配置打开的OAuth 2.0配置窗口。
在OAuth流场中，选择客户端。
在OAuth端点字段中，选择自定义。
在相应字段中指定您的 OAuth 2.0 端点和您分配给 Google 的客户端 ID。
在步骤1部分，不要选择任何谷歌范围。相反，将此字段留空或键入对您的服务器有效的范围（如果不使用 OAuth 范围，则输入任意字符串）。当您完成后，单击授权的API。
在步骤2和步骤3段，完成OAuth 2.0流程和验证每个步骤按预期工作。

您可以通过验证您的实现谷歌帐户链接演示工具。

在工具中，执行以下步骤：

点击登录在与谷歌按钮。
选择您要关联的帐户。
输入服务标识。
（可选）输入您将请求访问的一个或多个范围。
单击开始演示。
出现提示时，确认您可以同意并拒绝链接请求。
确认您被重定向到您的平台。