Association du compte Google avec OAuth (flux implicite – archivé)

Pour prendre en charge le flux implicite OAuth 2.0, votre service met à disposition un point de terminaison d'autorisation par HTTPS. Ce point de terminaison est responsable de l'authentification et de l'obtention du consentement des utilisateurs pour l'accès aux données. Le point de terminaison d'autorisation présente une UI de connexion à vos utilisateurs qui ne sont pas encore connectés et enregistre le consentement à 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 leur nom.

Association de compte Google : flux implicite OAuth

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

Utilisateur Application Google / Navigateur Votre point de terminaison d'authentification 1. L'utilisateur lance l'association 2. Rediriger vers le point de terminaison d'authentification (GET) client_id, redirect_uri, state, scope 3. Afficher l'écran de connexion et de consentement 4. L'utilisateur s'authentifie et donne son consentement 5. Rediriger vers Google avec le jeton (GET) access_token, state 6. Stocker des jetons utilisateur 7. Accéder aux ressources utilisateur
Figure 1. Séquence d'événements dans le flux implicite OAuth 2.0 pour l'association de compte Google.

Rôles et responsabilités

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

Acteur / Composant Rôle dans la LAG Responsabilités
Application / Serveur Google Client OAuth Lance le flux, reçoit le jeton d'accès à l'aide d'une redirection de navigateur et le stocke de manière sécurisée pour accéder aux API de votre service.
Votre point de terminaison d'autorisation Serveur d'autorisation authentifie vos utilisateurs, obtient leur consentement et émet des jetons d'accès de longue durée directement à Google.
URI de redirection Google Point de terminaison de rappel Reçoit la redirection de l'utilisateur depuis votre service d'autorisation avec les valeurs access_token et state dans le fragment d'URL.

Une session de flux implicite OAuth 2.0 type initiée par Google se déroule comme suit :

  1. Google ouvre votre point de terminaison d'autorisation dans le navigateur de l'utilisateur. 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.
  2. Votre service crée un jeton d'accès et le renvoie à Google. Pour ce faire, redirigez le navigateur de l'utilisateur vers Google en joignant le jeton d'accès à la requête.
  3. Google appelle les API de votre service et joint le jeton d'accès à chaque requête. Votre service vérifie que le jeton d'accès autorise Google à accéder à l'API, puis exécute l'appel d'API.

Recette d'implémentation

Pour implémenter le flux implicite, procédez comme suit.

Étape 1 : Gérez les demandes d'autorisation

Lorsque Google lance l'association de compte, il redirige l'utilisateur vers votre point de terminaison d'autorisation. Pour en savoir plus sur les contrats de protocole et les exigences concernant les paramètres, consultez Point de terminaison d'autorisation.

Pour traiter la demande, procédez comme suit :

  1. Validez la demande :

    • Vérifiez que client_id correspond à l'ID client attribué à Google.
    • Vérifiez que redirect_uri correspond à l'URL de redirection Google attendue : none https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
    • Vérifiez que response_type est défini sur token.

  2. Authentifiez l'utilisateur :

    • Vérifiez si l'utilisateur est connecté à votre service.
    • Si l'utilisateur n'est pas connecté, invitez-le à suivre votre procédure de connexion ou d'inscription.

  3. Générez un jeton d'accès :

    • Créez un jeton d'accès unique et difficile à deviner, associé à l'utilisateur et au client.

  4. Rediriger vers Google :

    • Redirigez le navigateur vers l'URL fournie dans redirect_uri.
    • Ajoutez les paramètres suivants dans le fragment d'URL (hachage) :
      • access_token : jeton d'accès que vous avez généré.
      • token_type : doit être bearer.
      • state : valeur d'état non modifiée reçue de Google.
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:

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:

  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.