Grâce à l'association des comptes Google, les titulaires de comptes Google peuvent se connecter rapidement, facilement et en toute sécurité à vos services, et partager des données avec Google.
La fonctionnalité de connexion avec un compte associé active la connexion avec One Tap avec Google pour les utilisateurs qui ont déjà associé leur compte Google à votre service. Les utilisateurs peuvent ainsi se connecter en un clic, sans avoir à saisir à nouveau leur nom d'utilisateur et leur mot de passe. Cela réduit également le risque que les utilisateurs créent des comptes en double sur votre service.
Conditions requises
Pour mettre en œuvre la connexion avec le compte associé, vous devez remplir les conditions suivantes:
- Vous disposez d'une association avec Google Account OAuth compatible avec le flux de code d'autorisation OAuth 2.0. Votre mise en œuvre OAuth doit inclure les points de terminaison suivants :
- point de terminaison d'autorisation pour gérer les demandes d'autorisation.
- point de terminaison du jeton pour gérer la demande d'accès et l'actualisation des jetons.
- userinfo point de terminaison pour récupérer les informations de base sur le compte associé, visibles par l'utilisateur lors du processus de connexion au compte associé.
- Vous disposez d'une application Android.
Fonctionnement
Condition préalable : l'utilisateur a déjà associé ses comptes Google et Google Ads.
- Vous activez l'affichage des comptes associés lors de la procédure de connexion avec One Tap.
- L'utilisateur reçoit une invite de connexion One Tap avec possibilité de se connecter à votre service avec son compte associé.
- Si l'utilisateur choisit de continuer avec le compte associé, Google envoie une requête au point de terminaison de votre jeton pour enregistrer un code d'autorisation. La requête contient le jeton d'accès de l'utilisateur émis par votre service et un code d'autorisation Google.
- Vous échangez le code d'autorisation Google contre un jeton d'ID Google contenant des informations sur le compte Google de l'utilisateur.
- Votre application reçoit également un jeton d'ID, une fois le flux terminé, et comparé l'identifiant utilisateur du jeton d'ID reçu par votre serveur afin de connecter l'utilisateur à votre application.
Mettre en œuvre la connexion de compte associé dans votre application Android
Pour utiliser la fonctionnalité de connexion au compte associé dans votre application Android, suivez les instructions du Guide de mise en œuvre Android.
Gérer les requêtes de code d'autorisation de Google
Google envoie une requête POST au point de terminaison de votre jeton pour enregistrer un code d'autorisation que vous échangez contre le jeton d'ID de l'utilisateur. La requête contient le jeton d'accès de l'utilisateur et un code d'autorisation OAuth2 émis par Google.
Avant d'enregistrer le code d'autorisation, vous devez vérifier que vous avez accordé à Google le jeton d'accès identifié par le client_id.
Requête HTTP
Exemple de requête
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
code=GOOGLE_AUTHORIZATION_CODE
&grant_type=urn:ietf:params:oauth:grant-type:reciprocal
&client_id=CLIENT_ID
&client_secret=CLIENT_SECRET
&access_token=ACCESS_TOKEN
Votre point de terminaison d'échange de jetons doit pouvoir gérer les paramètres de requête suivants:
| Paramètres du point de terminaison du jeton | |
|---|---|
code |
Obligatoire Code d'autorisation Google OAuth2 |
client_id |
Obligatoire ID client que vous avez envoyé à Google |
client_secret |
Obligatoire Code secret du client que vous avez envoyé à Google |
access_token |
Obligatoire : jeton d'accès que vous avez émis à Google. Il vous permettra d'obtenir le contexte de l'utilisateur. |
grant_type |
Obligatoire La valeur DOIT être définie sur urn:ietf:params:oauth:grant-type:reciprocal. |
Votre point de terminaison d'échange de jetons doit répondre à la requête POST en procédant comme suit:
- Vérifiez que l'ID
access_tokena été accordé à Google identifié par l'élémentclient_id. - Utilisez une réponse HTTP 200 (OK) si la requête est valide et si le code d'authentification est échangé avec un jeton d'ID Google, ou un code d'erreur HTTP si la requête n'est pas valide.
Réponse HTTP
Réussite
Afficher le code d'état HTTP 200 OK
Exemple de réponse positive
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{}
Erreurs
Dans le cas d'une requête HTTP non valide, répondez avec l'un des codes d'erreur HTTP suivants:
| HTTP Status Code | Corps | Description |
|---|---|---|
| 400 | {"error": "invalid_request"} |
Un paramètre est manquant dans la demande. Le serveur ne peut donc pas la traiter. Cette valeur peut également être renvoyée si la requête inclut un paramètre non accepté ou répète un paramètre. |
| 401 | {"error": "invalid_request"} |
Échec de l'authentification client, par exemple si la requête contient un ID client ou un secret non valides |
| 401 | {"error": "invalid_token"}
Inclure le challenge "WWW-Authentication: Bearer" auth challenge" dans l'en-tête de réponse |
Le jeton d'accès du partenaire n'est pas valide. |
| 403 | {"error": "insufficient_permission"}
Inclure le challenge "WWW-Authentication: Bearer" auth challenge" dans l'en-tête de réponse |
Le jeton d'accès du partenaire ne contient pas le ou les champs d'application nécessaires pour effectuer l'authentification OAuth réciproque. |
| 500 | {"error": "internal_error"} |
Erreur du serveur |
La réponse d'erreur doit contenir les champs suivants :
| Champs de réponse d'erreur | |
|---|---|
error |
Obligatoire Chaîne d'erreur |
error_description |
Description lisible de l'erreur |
error_uri |
URI qui fournit plus de détails sur l'erreur |
Exemple de réponse 400
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"error": "invalid_request",
"error_description": "Request was missing the 'access_token' parameter."
}
Code d'autorisation Exchange pour le jeton d'ID
Vous devez échanger le code d'autorisation que vous avez reçu contre un jeton d'ID Google contenant des informations sur le compte Google de l'utilisateur.
Pour échanger un code d'autorisation contre un jeton d'ID Google, appelez le point de terminaison https://oauth2.googleapis.com/token et définissez les paramètres suivants:
| Champs des demandes | |
|---|---|
client_id |
Obligatoire : ID client obtenu sur la page Identifiants de la console API. Il s'agit généralement de l'identifiant appelé Nouvelles actions sur Google. |
client_secret |
Obligatoire : code secret du client obtenu sur la page Identifiants de la console API |
code |
Obligatoire : code d'autorisation envoyé dans la requête initiale |
grant_type |
Obligatoire tel que défini dans la spécification OAuth 2.0, la valeur de ce champ doit être définie sur authorization_code. |
Exemple de requête
POST /oauth2/v4/token HTTP/1.1
Host: www.googleapis.com
Content-Type: application/x-www-form-urlencoded
code=GOOGLE_AUTHORIZATION_CODE
&grant_type=authorization_code
&client_id=GOOGLE_CLIENT_ID
&client_secret=GOOGLE_CLIENT_SECRET
Pour répondre à cette requête, Google renvoie un objet JSON contenant un jeton d'accès de courte durée et un jeton d'actualisation.
La réponse contient les champs suivants :
| Champs de réponse | |
|---|---|
access_token |
Jeton d'accès émis par Google que votre application envoie pour autoriser une requête API Google |
id_token |
Le jeton d'ID contient les informations du compte Google de l'utilisateur. La section Valider la réponse contient des informations sur le décodage et la validation de la réponse du jeton d'ID. |
expires_in |
Durée de vie restante du jeton d'accès en secondes |
refresh_token |
Jeton que vous pouvez utiliser pour obtenir un nouveau jeton d'accès. Les jetons d'actualisation sont valides jusqu'à ce que l'utilisateur révoque l'accès |
scope |
La valeur de ce champ est toujours définie sur openid pour le cas d'utilisation de la connexion au compte associé. |
token_type |
Type de jeton renvoyé. Pour l'instant, la valeur de ce champ est toujours définie sur Bearer. |
Exemple de réponse
HTTP/1.1 200 OK
Content-type: application/json; charset=utf-8
{
"access_token": "Google-access-token",
"id_token": "Google-ID-token",
"expires_in": 3599,
"token_type": "Bearer",
"scope": "openid",
"refresh_token": "Google-refresh-token"
}
POST /oauth2/v4/token HTTP/1.1
Host: www.googleapis.com
Content-Type: application/x-www-form-urlencoded
code=Google authorization code
&grant_type=authorization_code
&client_id=Google client id
&client_secret=Google client secret
Valider la réponse du jeton d'ID
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é:
-
emaila un suffixe@gmail.com, c'est un compte Gmail. -
email_verifiedest true ethdest 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.