Présentation
L'association simplifiée Google Sign-In à Google Sign-In vient compléter l'association OAuth. Les utilisateurs de Google bénéficient ainsi d'une expérience fluide. De plus, ils peuvent créer un compte, ce qui leur permet de créer un compte sur votre service à l'aide de leur compte Google.
Pour effectuer l'association de comptes avec OAuth et Google Sign-In, procédez comme suit:
- Tout d'abord, demandez à l'utilisateur d'autoriser l'accès à son profil Google.
- Utilisez les informations de leur profil pour vérifier si le compte utilisateur existe.
- Pour les utilisateurs existants, associez les comptes.
- Si vous ne trouvez pas de correspondance pour l'utilisateur Google dans votre système d'authentification, validez le jeton d'ID envoyé par Google. Vous pouvez ensuite créer un utilisateur à partir des informations de profil contenues dans le jeton d'ID.

Figure 1 : Association de compte sur le téléphone d'un utilisateur avec l'association simplifiée
Conditions requises pour l'association simplifiée
- Mettez en œuvre le flux Association de base Web OAuth. Votre service doit être compatible avec les points de terminaison d'autorisation et d'échange de jetons conformes à OAuth 2.0.
- Votre point de terminaison Token Exchange doit accepter les assertions JSON Web Token (JWT) et implémenter les intents
check
,create
etget
.
Implémenter votre serveur OAuth
Votre point de terminaison d'échange de jetons doit accepter les intents check
, create
et get
. Vous trouverez ci-dessous les étapes terminées lors du processus d'association de comptes, ainsi que le moment où les différents intents sont appelés:
- L'utilisateur possède-t-il un compte dans votre système d'authentification ? (L'utilisateur décide en sélectionnant "OUI" ou "NON")
- OUI : l'utilisateur se sert-il de l'adresse e-mail associée à son compte Google pour se connecter à votre plate-forme ? (L'utilisateur décide en sélectionnant "OUI" ou "NON")
- OUI : l'utilisateur a-t-il un compte correspondant dans votre système d'authentification ? (
check intent
est appelé pour confirmer).- OUI :
get intent
est appelé et le compte est associé si l'intent get renvoie un résultat positif. - NON : Créer un compte ? (L'utilisateur décide en sélectionnant "OUI" ou "NON")
- OUI : la méthode
create intent
est appelée. Si l'intent de création est bien renvoyé, le compte est associé. - NON : le flux OAuth Web est déclenché, l'utilisateur est dirigé vers son navigateur et il a la possibilité de créer une association à une autre adresse e-mail.
- OUI : la méthode
- OUI :
- NON : le flux OAuth du Web est déclenché, et l'utilisateur est redirigé vers son navigateur et a la possibilité de créer une association à une autre adresse e-mail.
- OUI : l'utilisateur a-t-il un compte correspondant dans votre système d'authentification ? (
- NON : l'utilisateur dispose-t-il d'un compte correspondant dans votre système d'authentification ? (
check intent
est appelé pour confirmer).- OUI :
get intent
est appelé et le compte est associé si l'intent get renvoie un résultat positif. - NON :
create intent
est appelé et le compte est associé si l'intent de création aboutit.
- OUI :
- OUI : l'utilisateur se sert-il de l'adresse e-mail associée à son compte Google pour se connecter à votre plate-forme ? (L'utilisateur décide en sélectionnant "OUI" ou "NON")
Rechercher un compte utilisateur existant (vérifier l'intent)
Une fois que l'utilisateur a autorisé l'accès à son profil Google, Google envoie une requête contenant une assertion signée de l'identité de l'utilisateur Google. L'assertion contient des informations qui incluent l'ID de compte Google, le nom et l'adresse e-mail de l'utilisateur. Le point de terminaison d'échange de jetons configuré pour votre projet gère cette requête.
Si le compte Google correspondant est déjà présent dans votre système d'authentification, votre point de terminaison d'échange de jetons répond avec account_found=true
. Si le compte Google ne correspond à aucun utilisateur existant, le point de terminaison de votre échange de jetons affiche une erreur HTTP 404 "Introuvable" avec account_found=false
.
La requête se présente comme suit:
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&client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET
Votre point de terminaison d'échange de jetons doit pouvoir gérer les paramètres suivants:
Paramètres du point de terminaison du jeton | |
---|---|
intent |
Pour ces requêtes, la valeur de ce paramètre est check . |
grant_type |
Type de jeton échangé. Pour ces requêtes, ce paramètre a la valeur urn:ietf:params:oauth:grant-type:jwt-bearer . |
assertion |
Jeton Web JSON (JWT, JSON Web Token) qui fournit une assertion signée de l'identité de l'utilisateur Google. Le jeton JWT contient des informations qui incluent l'ID de compte, le nom et l'adresse e-mail du compte Google de l'utilisateur. |
client_id |
ID client que vous avez attribué à Google. |
client_secret |
Code secret du client que vous avez attribué à Google. |
Pour répondre aux requêtes d'intent check
, le point de terminaison de votre échange de jetons doit procéder comme suit:
- Validez et décodez l'assertion JWT.
- Vérifiez si le compte Google existe déjà dans votre système d'authentification.
Valider et décoder l'assertion JWT
Vous pouvez valider et décoder l'assertion JWT à l'aide d'une bibliothèque de décodage JWT pour votre langue . Utilisez les clés publiques de Google, disponibles aux formats JWK ou PEM , pour vérifier la signature du jeton.
Une fois décodée, l'assertion JWT ressemble à l'exemple suivant:
{ "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 }
En plus de vérifier la signature du jeton, vérifiez que l'émetteur de l'assertion (champ iss
) est https://accounts.google.com
, que l'audience (champ aud
) est votre ID client attribué et que le jeton n'a pas expiré ( exp
domaine).
En utilisant les champs email
, email_verified
et hd
, vous pouvez déterminer si Google héberge et fait autorité pour une adresse e-mail. Dans les cas où Google fait autorité, l'utilisateur est actuellement connu comme le propriétaire légitime du compte et vous pouvez ignorer le mot de passe ou d'autres méthodes de contestation. Sinon, ces méthodes peuvent être utilisées pour vérifier le compte avant de lier.
Cas où Google fait autorité:
-
email
a un suffixe@gmail.com
, c'est un compte Gmail. -
email_verified
est true ethd
est défini, il s'agit d'un compte G Suite.
Les utilisateurs peuvent s'inscrire à des comptes Google sans utiliser Gmail ou G Suite. Lorsque l' email
- email
ne contient pas de suffixe @gmail.com
et que hd
est absent, Google ne fait pas autorité et un mot de passe ou d'autres méthodes de défi sont recommandés pour vérifier l'utilisateur. email_verfied
peut également être vrai car Google a initialement vérifié l'utilisateur lors de la création du compte Google, mais la propriété du compte de messagerie tiers peut avoir changé depuis.
Vérifiez si le compte Google est déjà présent dans votre système d'authentification.
Vérifiez si l'une des conditions suivantes est remplie:
- L'ID de compte Google, figurant dans le champ
sub
des assertions, se trouve dans votre base de données utilisateur. - L'adresse e-mail indiquée dans cette assertion correspond à un utilisateur de votre base de données.
Si l'une des deux conditions est remplie, l'utilisateur s'est déjà inscrit. Dans ce cas, renvoyez une réponse semblable à celle-ci:
HTTP/1.1 200 Success Content-Type: application/json;charset=UTF-8 { "account_found":"true", }
Si ni l'ID de compte Google, ni l'adresse e-mail spécifiées dans l'assertion ne correspondent à un utilisateur de votre base de données, celui-ci ne s'est pas encore inscrit. Dans ce cas, le point de terminaison de votre échange de jetons doit répondre par une erreur HTTP 404 spécifiant "account_found": "false"
, comme dans l'exemple suivant:
HTTP/1.1 404 Not found Content-Type: application/json;charset=UTF-8 { "account_found":"false", }
Handle automatic linking (get 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 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&client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET
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. |
client_id |
The client ID you assigned to Google. |
client_secret |
The client secret you assigned to Google. |
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.
Valider et décoder l'assertion JWT
Vous pouvez valider et décoder l'assertion JWT à l'aide d'une bibliothèque de décodage JWT pour votre langue . Utilisez les clés publiques de Google, disponibles aux formats JWK ou PEM , pour vérifier la signature du jeton.
Une fois décodée, l'assertion JWT ressemble à l'exemple suivant:
{ "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 }
En plus de vérifier la signature du jeton, vérifiez que l'émetteur de l'assertion (champ iss
) est https://accounts.google.com
, que l'audience (champ aud
) est votre ID client attribué et que le jeton n'a pas expiré ( exp
domaine).
En utilisant les champs email
, email_verified
et hd
, vous pouvez déterminer si Google héberge et fait autorité pour une adresse e-mail. Dans les cas où Google fait autorité, l'utilisateur est actuellement connu comme le propriétaire légitime du compte et vous pouvez ignorer le mot de passe ou d'autres méthodes de contestation. Sinon, ces méthodes peuvent être utilisées pour vérifier le compte avant de lier.
Cas où Google fait autorité:
-
email
a un suffixe@gmail.com
, c'est un compte Gmail. -
email_verified
est true ethd
est défini, il s'agit d'un compte G Suite.
Les utilisateurs peuvent s'inscrire à des comptes Google sans utiliser Gmail ou G Suite. Lorsque l' email
- email
ne contient pas de suffixe @gmail.com
et que hd
est absent, Google ne fait pas autorité et un mot de passe ou d'autres méthodes de défi sont recommandés pour vérifier l'utilisateur. email_verfied
peut également être vrai car Google a initialement vérifié l'utilisateur lors de la création du compte Google, mais la propriété du compte de messagerie tiers peut avoir changé depuis.
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&client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET
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. |
client_id |
The client ID you assigned to Google. |
client_secret |
The client secret you assigned to Google. |
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.
Valider et décoder l'assertion JWT
Vous pouvez valider et décoder l'assertion JWT à l'aide d'une bibliothèque de décodage JWT pour votre langue . Utilisez les clés publiques de Google, disponibles aux formats JWK ou PEM , pour vérifier la signature du jeton.
Une fois décodée, l'assertion JWT ressemble à l'exemple suivant:
{ "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 }
En plus de vérifier la signature du jeton, vérifiez que l'émetteur de l'assertion (champ iss
) est https://accounts.google.com
, que l'audience (champ aud
) est votre ID client attribué et que le jeton n'a pas expiré ( exp
domaine).
En utilisant les champs email
, email_verified
et hd
, vous pouvez déterminer si Google héberge et fait autorité pour une adresse e-mail. Dans les cas où Google fait autorité, l'utilisateur est actuellement connu comme le propriétaire légitime du compte et vous pouvez ignorer le mot de passe ou d'autres méthodes de contestation. Sinon, ces méthodes peuvent être utilisées pour vérifier le compte avant de lier.
Cas où Google fait autorité:
-
email
a un suffixe@gmail.com
, c'est un compte Gmail. -
email_verified
est true ethd
est défini, il s'agit d'un compte G Suite.
Les utilisateurs peuvent s'inscrire à des comptes Google sans utiliser Gmail ou G Suite. Lorsque l' email
- email
ne contient pas de suffixe @gmail.com
et que hd
est absent, Google ne fait pas autorité et un mot de passe ou d'autres méthodes de défi sont recommandés pour vérifier l'utilisateur. email_verfied
peut également être vrai car Google a initialement vérifié l'utilisateur lors de la création du compte Google, mais la propriété du compte de messagerie tiers peut avoir changé depuis.
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" }
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.
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 }
Obtenir votre ID client pour les API Google
Vous devrez fournir votre ID client pour l'API Google lors du processus d'enregistrement de l'association de comptes.
Pour obtenir votre ID client d'API à l'aide du projet que vous avez créé lors de la procédure d'association OAuth, procédez comme suit : Pour cela, procédez comme suit :
- Ouvrez la page Identifiants de la console Google APIs.
Créez ou sélectionnez un projet d'API Google.
Si votre projet ne dispose pas d'un ID client pour le type d'application Web, cliquez sur Créer des identifiants > ID client OAuth pour en créer un. Veillez à inclure le domaine de votre site dans le champ Origines JavaScript autorisées. Lorsque vous effectuez des tests ou un développement en local, vous devez ajouter
http://localhost
ethttp://localhost:<port_number>
au champ Origines JavaScript autorisées.
Valider votre intégration
Vous pouvez valider votre implémentation en utilisant le Playground OAuth 2.0 outil.
Dans l'outil, procédez comme suit :
- Cliquez sur Configuration des pour ouvrir la fenêtre Configuration OAuth 2.0.
- Dans le champ d'écoulement OAuth, sélectionnez côté client.
- Dans le domaine Endpoints OAuth, sélectionnez Personnalisé.
- Spécifiez votre point de terminaison OAuth 2.0 et l'ID client que vous avez attribué à Google dans les champs correspondants.
- Dans la section Étape 1, ne sélectionnez pas de champs Google. Au lieu de cela, laissez ce champ vide ou saisissez une étendue valide pour votre serveur (ou une chaîne arbitraire si vous n'utilisez pas d'étendues OAuth). Lorsque vous avez terminé, cliquez sur Autoriser les API.
- Dans les étapes 2 et 3 sections, passez par le flux OAuth 2.0 et vérifiez que chaque étape fonctionne comme prévu.
Vous pouvez valider votre implémentation en utilisant le compte Google Linking Demo outil.
Dans l'outil, procédez comme suit :
- Cliquez sur le signe-avec le bouton Google.
- Choisissez le compte que vous souhaitez associer.
- Saisissez l'ID du service.
- Saisissez éventuellement une ou plusieurs étendues pour lesquelles vous demanderez l'accès.
- Cliquez sur Démarrer démo.
- Lorsque vous y êtes invité, confirmez que vous pouvez consentir et refuser la demande d'association.
- Confirmez que vous êtes redirigé vers votre plateforme.