Cette page a été traduite par l'API Cloud Translation.

Association de comptes Google avec OAuth

Les comptes sont associés à l'aide des flux implicites et codes d'autorisation OAuth 2.0 standards dans l'industrie. Votre service doit prendre en charge les points de terminaison d'autorisation et d'échange de jetons conformes à OAuth 2.0.

Dans le flux implicite, Google ouvre votre point de terminaison d'autorisation dans le navigateur de l'utilisateur. Une fois la connexion réussie, vous renvoyez un jeton d'accès à durée de vie prolongée à Google. Ce jeton d'accès est désormais inclus dans chaque requête envoyée par Google.

Dans le flux code d'autorisation, vous avez besoin de deux points de terminaison:

Le point de terminaison d'autorisation, qui présente l'UI de connexion à vos utilisateurs qui ne sont pas encore connectés. Le point de terminaison d'autorisation crée également un code d'autorisation de courte durée pour enregistrer le consentement des utilisateurs à l'accès demandé.
Le point de terminaison échange de jetons, qui est responsable de deux types d'échanges:
1. Échange un code d'autorisation contre un jeton d'actualisation de longue durée et un jeton d'accès de courte durée. Cet échange se produit lorsque l'utilisateur suit le parcours d'association de compte.
2. Échange un jeton d'actualisation à longue durée de vie contre un jeton d'accès à courte durée de vie. Cet échange se produit lorsque Google a besoin d'un nouveau jeton d'accès, car celui-ci a expiré.

Choisir un flux OAuth 2.0

Bien que le flux implicite soit plus simple à implémenter, Google recommande que les jetons d'accès émis par le flux implicite n'expirent jamais. En effet, l'utilisateur est obligé d'associer à nouveau son compte après l'expiration d'un jeton avec le flux implicite. Si vous avez besoin d'une expiration des jetons pour des raisons de sécurité, nous vous recommandons vivement d'utiliser plutôt le flux avec code d'autorisation.

Principes de conception

Cette section décrit les exigences de conception et les recommandations concernant l'écran utilisateur que vous hébergez pour les flux d'association OAuth. Une fois qu'elle est appelée par l'application Google, votre plate-forme affiche une page de connexion à Google et un écran de consentement pour l'association de compte à l'utilisateur. L'utilisateur est redirigé vers l'application Google après avoir donné son autorisation pour associer des comptes.

Cette figure montre comment un utilisateur peut associer son compte Google à votre système d'authentification. La première capture d'écran montre l'association lancée par l'utilisateur depuis votre plate-forme. La deuxième image montre la connexion de l'utilisateur à Google, tandis que la troisième montre le consentement et la confirmation de l'utilisateur pour associer son compte Google à votre application. La dernière capture d'écran montre un compte utilisateur associé avec succès dans l'application Google. — **Figure 1** Connexion de l'utilisateur à Google pour l'association de compte et écrans de consentement

Conditions requises

Vous devez indiquer que le compte de l'utilisateur sera associé à Google, et non à un produit Google spécifique tel que Google Home ou l'Assistant Google.

Recommandations

Nous vous recommandons d'effectuer les opérations suivantes :

Afficher les règles de confidentialité de Google. Incluez un lien vers les Règles de confidentialité de Google sur l'écran de consentement.
Données à partager. Utilisez un langage clair et concis pour indiquer à l'utilisateur quelles données Google exige et pourquoi.
Incitation à l'action claire Énoncez une incitation à l'action claire sur votre écran de consentement, par exemple "Accepter et associer". En effet, les utilisateurs doivent comprendre quelles données ils doivent partager avec Google pour associer leurs comptes.
Possibilité d'annuler. Proposez aux utilisateurs la possibilité de revenir en arrière ou d'annuler s'ils choisissent de ne pas associer leur compte.
Procédure de connexion claire. Assurez-vous que les utilisateurs disposent d'une méthode claire pour se connecter à leur compte Google, comme des champs pour leur nom d'utilisateur et leur mot de passe ou Se connecter avec Google.
Possibilité de dissocier : Offrez aux utilisateurs un mécanisme de dissociation, par exemple une URL vers les paramètres de leur compte sur votre plate-forme. Vous pouvez également inclure un lien vers le compte Google, où les utilisateurs peuvent gérer leur compte associé.
Possibilité de changer de compte utilisateur Suggérez aux utilisateurs une méthode pour changer de compte. Cette fonctionnalité est particulièrement utile si les utilisateurs ont tendance à posséder plusieurs comptes.
- Si un utilisateur doit fermer l'écran d'autorisation pour changer de compte, envoyez une erreur récupérable à Google afin qu'il puisse se connecter au compte souhaité avec l'association OAuth et le parcours implicite.
Incluez votre logo. Afficher le logo de votre entreprise sur l'écran de consentement. Utilisez vos consignes de style pour placer votre logo. Si vous souhaitez également afficher le logo de Google, consultez la section Logos et marques.

Créer le projet

Pour créer votre projet afin d'utiliser l'association de comptes:

Go to the Google API Console.
Click Create project.
Enter a name or accept the generated suggestion.
Confirm or edit any remaining fields.
Click Create.

To view your project ID:

Go to the Google API Console.
Find your project in the table on the landing page. The project ID appears in the ID column.

Configurer votre écran de consentement OAuth

Le processus d'association du compte Google comprend un écran de consentement qui indique aux utilisateurs l'application qui demande à accéder à leurs données, le type de données qu'ils demandent et les conditions applicables. Vous devez configurer votre écran de consentement OAuth avant de générer un ID client pour les API Google.

Ouvrez l'écran d'autorisation OAuth dans la console des API Google.
Si vous y êtes invité, sélectionnez le projet que vous venez de créer.
Sur la page "Écran d'autorisation 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 celui que les utilisateurs voient ailleurs. Le nom de l'application s'affiche sur l'écran d'autorisation de l'association de comptes.

Logo de l'application:image affichée sur l'écran de consentement pour aider les utilisateurs à reconnaître votre application. Le logo s'affiche sur l'écran de consentement à 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 concernant leur consentement.

Champs d'application pour les API Google:les champs d'application permettent à votre application d'accéder aux données Google privées de vos utilisateurs. Pour le cas d'utilisation de l'association de compte Google, le champ d'application par défaut (adresse e-mail, profil, OpenID) est suffisant. Vous n'avez pas besoin d'ajouter de champ d'application sensible. Il est généralement recommandé de demander des portées de manière incrémentielle, au moment où l'accès est requis, plutôt que d'emblée. En savoir plus

Domaines autorisés:pour vous protéger, vous et vos utilisateurs, Google n'autorise que les applications qui s'authentifient à l'aide d'OAuth à utiliser des domaines autorisés. 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. Il doit être hébergé sur un domaine autorisé.

Lien vers les règles de confidentialité de l'application:s'affiche sur l'écran d'autorisation de l'association de comptes Google. Il 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 d'un compte Google à une application fictive, Tunery
Vérifiez l'état de validation. Si votre application doit être validée, cliquez sur le bouton "Envoyer pour validation". Pour en savoir plus, consultez les Exigences de validation OAuth.

Implémenter votre serveur OAuth

Pour prendre en charge le flux implicite OAuth 2.0, votre service accorde une autorisation un point de terminaison unique disponible via HTTPS. Ce point de terminaison est responsable de l'authentification l'obtention du consentement des utilisateurs pour l'accès aux données. Le point de terminaison d'autorisation présente une interface utilisateur de connexion aux utilisateurs qui ne sont pas déjà connectés et enregistre autoriser l'accès demandé.

Lorsqu'une application Google doit appeler l'une des API autorisées de votre service, Google utilise ce point de terminaison pour obtenir l'autorisation de vos utilisateurs d'appeler ces API en son nom.

Une session de flux implicite OAuth 2.0 typique lancée par Google possède le flux suivant:

Google ouvre votre point de terminaison d'autorisation dans le navigateur de l'utilisateur. La se connecte (s'il ne l'est pas déjà) et autorise Google à accéder à leurs données avec votre API, s'ils ne l'ont pas déjà accordé.
Votre service crée un jeton d'accès et le renvoie à Google Pour ce faire, redirigez le navigateur de l'utilisateur vers Google associé à la requête.
Google appelle les API de votre service et associe le jeton d'accès chaque requête. Votre service vérifie que le jeton d'accès accorde à Google l'autorisation d'accès à l'API, puis termine l'appel d'API.

Gérer les requêtes d'autorisation

Lorsqu'une application Google doit associer un compte via une méthode OAuth 2.0 flux implicite, Google redirige l'utilisateur vers votre point de terminaison d'autorisation qui inclut les paramètres suivants:

Paramètres du point de terminaison de l'autorisation
`client_id`	ID client que vous avez attribué à Google.
`redirect_uri`	URL à laquelle vous envoyez la réponse à cette requête.
`state`	Une valeur de tenue de registre renvoyée à Google telle quelle dans le l'URI de redirection.
`response_type`	Type de valeur à renvoyer dans la réponse. Pour l'authentification OAuth 2.0 le type de réponse est toujours `token`.
`user_locale`	Le paramètre linguistique du compte Google RFC5646 format utilisé pour localiser votre contenu dans la langue préférée de l'utilisateur.

Par exemple, si votre point de terminaison d'autorisation est disponible 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&response_type=token&user_locale=LOCALE

Pour que votre point de terminaison d'autorisation traite les requêtes de connexion, procédez comme suit : étapes:

Vérifiez les valeurs client_id et redirect_uri pour pour empêcher l'octroi d'accès à des applications clientes non intentionnelles ou mal configurées:
- Vérifiez que client_id correspond à l'ID client que vous attribué à Google.
- Vérifiez que l'URL spécifiée par redirect_uri a la forme suivante:
```
https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
```
Vérifiez si l'utilisateur est connecté à votre service. Si l'utilisateur n'est pas signé suivez la procédure de connexion ou d'inscription de votre service.
Générez un jeton d'accès que Google utilisera pour accéder à votre API. La Le jeton d'accès peut correspondre à n'importe quelle valeur de chaîne, mais il doit représenter de manière unique le user et le client pour lequel le jeton est destiné et ne doit pas être devinable.
Envoyer une réponse HTTP qui redirige le navigateur de l'utilisateur vers l'URL spécifiée par le paramètre redirect_uri. Incluez tous les les paramètres suivants dans le fragment d'URL:
- access_token: jeton d'accès que vous venez de générer
- token_type: chaîne bearer
- state: valeur de l'état non modifié de l'original demander
Voici un exemple de l'URL obtenue:
```
https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID#access_token=ACCESS_TOKEN&token_type=bearer&state=STATE_STRING
```

Le gestionnaire de redirection OAuth 2.0 de Google reçoit le jeton d'accès et confirme que la valeur state n'a pas changé. Une fois que Google a obtenu pour votre service, le jeton est associé aux appels suivants à vos API de service.

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.

userinfo endpoint request headers
`Authorization header`	The access token of type Bearer.

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:

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

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:

Click Configuration to open the OAuth 2.0 Configuration window.
In the OAuth flow field, select Client-side.
In the OAuth Endpoints field, select Custom.
Specify your OAuth 2.0 endpoint and the client ID you assigned to Google in the corresponding fields.
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.
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.