Association de comptes Google avec OAuth

Pour créer votre projet afin d'associer des comptes :

1. Accédez à la console Google APIs.
2. Cliquez sur Create Project (Créer un projet).
3. Saisissez un nom ou acceptez la suggestion générée.
4. Confirmez ou modifiez les champs restants.
5. Cliquez sur Create (Créer).

Pour afficher l'ID de votre projet :

1. Accédez à la console Google APIs.
2. Recherchez votre projet dans le tableau de la page de destination. L'ID du projet s'affiche dans la colonne ID.

Configurer votre écran de consentement OAuth

Le processus d'association de comptes Google inclut un écran de consentement qui indique aux utilisateurs l'application qui demande l'accès à leurs données, le type de données demandé et les conditions applicables. Vous devez configurer votre écran de consentement OAuth avant de générer un ID client Google API.

1. Ouvrez la page Écran de consentement OAuth de la console Google APIs.
2. Si vous y êtes invité, sélectionnez le projet que vous venez de créer.

3. Sur la page "Écran de consentement OAuth", remplissez le formulaire, puis cliquez sur le bouton "Enregistrer".

   Nom de l'application : nom de l'application qui demande le consentement. Le nom doit refléter précisément votre application et être cohérent avec le nom de l'application que les utilisateurs voient ailleurs. Le nom de l'application s'affiche sur l'écran de consentement pour l'association de comptes.

   Logo de l'application : image sur l'écran de consentement qui aide les utilisateurs à reconnaître votre application. Le logo s'affiche sur l'écran de consentement pour l'association de comptes et dans les paramètres du compte.

   Adresse e-mail d'assistance : permet aux utilisateurs de vous contacter s'ils ont des questions sur leur consentement.

   Niveaux d'accès pour les API Google : les niveaux d'accès permettent à votre application d'accéder aux données Google privées de vos utilisateurs. Pour le cas d'utilisation de l'association de comptes Google, le niveau d'accès par défaut (e-mail, profil, OpenID) suffit. Vous n'avez pas besoin d'ajouter de niveaux d'accès sensibles. En règle générale, il est préférable de demander les niveaux d'accès de manière incrémentale, au moment où l'accès est requis, plutôt qu'à l'avance. En savoir plus.

   Domaines autorisés : pour garantir votre protection et celle de vos utilisateurs, Google limite l'utilisation de domaines autorisés aux applications qui s'authentifient à l'aide d'OAuth. Les liens de vos applications doivent être hébergés sur des domaines autorisés. En savoir plus.

   Lien vers la page d'accueil de l'application : page d'accueil de votre application. Doit être hébergée sur un domaine autorisé.

   Lien vers les règles de confidentialité de l'application : s'affiche sur l'écran de consentement pour l'association de comptes Google. Doit être hébergé sur un domaine autorisé.

   Lien vers les conditions d'utilisation de l'application (facultatif) : doit être hébergé sur un domaine autorisé.

   

   Figure 1 : Écran de consentement pour l'association de comptes Google pour une application fictive, Tunery

4. Vérifiez l'état de validation. Si votre application doit être validée, cliquez sur le bouton "Envoyer pour validation" pour l'envoyer. Pour en savoir plus, consultez les conditions de validation OAuth.

Implémenter votre serveur OAuth

Une implémentation de serveur OAuth 2.0 du flux de code d'autorisation se compose de deux points de terminaison que votre service met à disposition par HTTPS. Le premier point de terminaison est le point de terminaison d'autorisation, qui est chargé de trouver ou d'obtenir le consentement des utilisateurs pour l'accès aux données. Le point de terminaison d'autorisation présente une interface utilisateur de connexion à vos utilisateurs qui ne sont pas encore connectés et enregistre le consentement à l'accès demandé. Le deuxième point de terminaison est le point de terminaison d'échange de jetons, qui est utilisé pour obtenir des chaînes chiffrées, appelées jetons, qui autorisent un utilisateur à accéder à votre service.

Lorsqu'une application Google doit appeler l'une des API de votre service, Google utilise ces points de terminaison ensemble pour obtenir l'autorisation de vos utilisateurs d'appeler ces API en leur nom.

Association de compte Google : flux avec code d'autorisation OAuth

Le diagramme de séquence suivant détaille les interactions entre l'utilisateur, Google et les points de terminaison de votre service.

Rôles et responsabilités

Le tableau suivant définit les rôles et les responsabilités des acteurs du flux OAuth d'association de compte Google. Notez que dans GAL, Google agit en tant que client OAuth, tandis que votre service agit en tant que fournisseur d'identité/de services.

Une session de flux avec code d'autorisation OAuth 2.0 initiée par Google se déroule comme suit :

1. Google ouvre votre point de terminaison d'autorisation dans le navigateur de l'utilisateur. Si le flux a commencé sur un appareil vocal uniquement pour une Action, Google transfère l'exécution vers un téléphone.
2. L'utilisateur se connecte, s'il ne l'a pas déjà fait, et autorise Google à accéder à ses données avec votre API, s'il ne l'a pas déjà fait.
3. Votre service crée un code d'autorisation et le renvoie à Google. Pour ce faire, redirigez le navigateur de l'utilisateur vers Google en joignant le code d'autorisation à la requête.
4. Google envoie le code d'autorisation à votre point de terminaison d'échange de jetons, qui vérifie l'authenticité du code et renvoie un jeton d'accès et un jeton d'actualisation. Le jeton d'accès est un jeton de courte durée que votre service accepte comme identifiant pour accéder aux API. Le jeton d'actualisation est un jeton à longue durée de vie que Google peut stocker et utiliser pour acquérir de nouveaux jetons d'accès lorsqu'ils expirent.
5. Une fois que l'utilisateur a terminé le parcours d'association de compte, chaque requête ultérieure envoyée par Google contient un jeton d'accès.

Gérer les demandes d'autorisation

Lorsque vous devez associer un compte à l'aide du flux de code d'autorisation OAuth 2.0, Google redirige l'utilisateur vers votre point de terminaison d'autorisation avec une requête qui inclut les paramètres suivants :

Par exemple, si votre point de terminaison d'autorisation est disponible à l'adresse https://myservice.example.com/auth, une requête peut se présenter comme suit :

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code&user_locale=LOCALE

Pour que votre point de terminaison d'autorisation gère les demandes de connexion, procédez comme suit :

1. Vérifiez que client_id correspond à l'ID client que vous avez attribué à Google et que redirect_uri correspond à l'URL de redirection fournie par Google pour votre service. Ces vérifications sont importantes pour éviter d'accorder l'accès à des applications clientes non prévues ou mal configurées. Si vous êtes compatible avec plusieurs flux OAuth 2.0, vérifiez également que response_type est défini sur code.
2. Vérifiez si l'utilisateur est connecté à votre service. Si l'utilisateur n'est pas connecté, suivez la procédure de connexion ou d'inscription de votre service.
3. Générez un code d'autorisation que Google pourra utiliser pour accéder à votre API. Le code d'autorisation peut être n'importe quelle valeur de chaîne, mais il doit représenter de manière unique l'utilisateur, le client pour lequel le jeton est destiné et le délai d'expiration du code, et il ne doit pas être devinable. En général, vous émettez des codes d'autorisation qui expirent au bout de 10 minutes environ.
4. Vérifiez que l'URL spécifiée par le paramètre redirect_uri se présente au format suivant :

     https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
     https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
     

5. Redirige le navigateur de l'utilisateur vers l'URL spécifiée par le paramètre redirect_uri. Incluez le code d'autorisation que vous venez de générer et la valeur d'état d'origine non modifiée lorsque vous redirigez en ajoutant les paramètres code et state. Voici un exemple d'URL obtenue :

   https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

Traiter les demandes d'échange de jetons

Le point de terminaison d'échange de jetons de votre service est responsable de deux types d'échanges de jetons :

• Échanger des codes d'autorisation contre des jetons d'accès et d'actualisation
• Échanger des jetons d'actualisation contre des jetons d'accès

Les demandes d'échange de jetons incluent les paramètres suivants :

Échanger des codes d'autorisation contre des jetons d'accès et d'actualisation

Une fois que l'utilisateur s'est connecté et que votre point de terminaison d'autorisation renvoie un code d'autorisation temporaire à Google, Google envoie une requête à votre point de terminaison d'échange de jetons pour échanger le code d'autorisation contre un jeton d'accès et un jeton d'actualisation.

Pour ces requêtes, la valeur de grant_type est authorization_code et la valeur de code correspond à la valeur du code d'autorisation que vous avez précédemment accordé à Google. Voici un exemple de requête permettant d'échanger un code d'autorisation contre un jeton d'accès et un jeton d'actualisation :

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

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

Pour échanger des codes d'autorisation contre un jeton d'accès et un jeton d'actualisation, votre point de terminaison d'échange de jetons répond aux requêtes POST en exécutant les étapes suivantes :

1. Vérifiez que client_id identifie l'origine de la requête comme une origine autorisée et que client_secret correspond à la valeur attendue.
2. Vérifiez que le code d'autorisation est valide et n'a pas expiré, et que l'ID client spécifié dans la requête correspond à l'ID client associé au code d'autorisation.
3. Vérifiez que l'URL spécifiée par le paramètre redirect_uri est identique à la valeur utilisée dans la demande d'autorisation initiale.
4. Si vous ne pouvez pas valider tous les critères précédents, renvoyez une erreur HTTP 400 (Requête incorrecte) avec {"error": "invalid_grant"} comme corps.
5. Sinon, utilisez l'ID utilisateur du code d'autorisation pour générer un jeton d'actualisation et un jeton d'accès. Ces jetons peuvent être n'importe quelle valeur de chaîne, mais ils doivent représenter de manière unique l'utilisateur et le client pour lesquels le jeton est destiné, et ils ne doivent pas être devinables. Pour les jetons d'accès, enregistrez également leur délai d'expiration, qui est généralement d'une heure après leur émission. Les jetons d'actualisation n'expirent pas.
6. Renvoie l'objet JSON suivant dans le corps de la réponse HTTPS :

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "refresh_token": "REFRESH_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }

Google stocke le jeton d'accès et le jeton d'actualisation de l'utilisateur, et enregistre l'expiration du jeton d'accès. Lorsque le jeton d'accès expire, Google utilise le jeton d'actualisation pour obtenir un nouveau jeton d'accès à partir de votre point de terminaison d'échange de jetons.

Échanger des jetons d'actualisation contre des jetons d'accès

Lorsqu'un jeton d'accès expire, Google envoie une requête à votre point de terminaison d'échange de jetons pour échanger un jeton d'actualisation contre un nouveau jeton d'accès.

Pour ces requêtes, la valeur de grant_type est refresh_token et la valeur de refresh_token correspond à la valeur du jeton d'actualisation que vous avez précédemment accordé à Google. Voici un exemple de requête permettant d'échanger un jeton d'actualisation contre un jeton d'accès :

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

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

Pour échanger un jeton d'actualisation contre un jeton d'accès, votre point de terminaison d'échange de jetons répond aux requêtes POST en exécutant les étapes suivantes :

1. Vérifiez que client_id identifie l'origine de la requête comme étant Google et que client_secret correspond à la valeur attendue.
2. Vérifiez que le jeton d'actualisation est valide et que l'ID client spécifié dans la requête correspond à l'ID client associé au jeton d'actualisation.
3. Si vous ne pouvez pas valider tous les critères précédents, renvoyez une erreur HTTP 400 (Requête incorrecte) avec {"error": "invalid_grant"} comme corps.
4. Sinon, utilisez l'ID utilisateur du jeton d'actualisation pour générer un jeton d'accès. Ces jetons peuvent correspondre à n'importe quelle valeur de chaîne, mais ils doivent représenter de manière unique l'utilisateur et le client pour lesquels le jeton est destiné, et ils ne doivent pas être devinables. Pour les jetons d'accès, enregistrez également leur délai d'expiration, généralement une heure après leur émission.
5. Renvoie l'objet JSON suivant dans le corps de la réponse HTTPS :

   {
   "token_type": "Bearer",
   "access_token": "ACCESS_TOKEN",
   "expires_in": SECONDS_TO_EXPIRATION
   }

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.

Valider votre implémentation

You can validate your implementation by using the OAuth 2.0 Playground tool.

In the tool, do the following steps:

1. Click Configuration settings to open the OAuth 2.0 Configuration window.
2. In the OAuth flow field, select Client-side.
3. In the OAuth Endpoints field, select Custom.
4. Specify your OAuth 2.0 endpoint and the client ID you assigned to Google in the corresponding fields.
5. In the Step 1 section, don't select any Google scopes. Instead, leave this field blank or type a scope valid for your server (or an arbitrary string if you don't use OAuth scopes). When you're done, click Authorize APIs.
6. In the Step 2 and Step 3 sections, go through the OAuth 2.0 flow and verify that each step works as intended.

You can validate your implementation by using the Google Account Linking Demo tool.

In the tool, do the following steps:

1. Click the Sign in with Google button.
2. Choose the account you'd like to link.
3. Enter the service ID.
4. Optionally enter one or more scopes that you will request access for.
5. Click Start Demo.
6. When prompted, confirm that you may consent and deny the linking request.
7. Confirm that you are redirected to your platform.