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

Liens simplifiés avec OAuth et Google Sign-In

La connexion simplifiée à Google basée sur OAuth ajoute la connexion à Google en plus de la liaison OAuth . Cela offre une expérience d'association transparente pour les utilisateurs de Google et permet également d'associer des comptes aux utilisateurs qui se sont inscrits à votre service avec une identité autre que Google.

Pour effectuer l'association de compte avec OAuth et Google Sign-In, procédez comme suit:

  1. Tout d'abord, demandez à l'utilisateur de donner son consentement pour accéder à son profil Google.
  2. Utilisez les informations de leur profil pour vérifier si le compte utilisateur existe.
  3. Pour les utilisateurs existants, associez les comptes.
  4. Si vous ne trouvez pas de correspondance pour l'utilisateur Google dans votre système d'authentification, validez le jeton d'identification reçu de Google. Vous pouvez ensuite créer un utilisateur en fonction des informations de profil contenues dans le jeton ID.

Les comptes sont liés à l'aide de flux de codes implicites et d' autorisation OAuth 2.0. Votre service doit prendre en charge les points de terminaison d' autorisation et d' échange de jetons conformes à OAuth 2.0. En outre, votre point de terminaison d' échange de jetons doit prendre en charge les assertions JSON Web Token (JWT) et implémenter la check , la create et l' get intentions.

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 de longue durée à Google. Ce jeton d'accès est désormais inclus dans chaque demande envoyée par Google.

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

  • Le point de terminaison d' autorisation , qui présente l'interface utilisateur 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 d' échange de jetons , responsable de deux types d'échanges:

    1. Échange un code d'autorisation pour 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 passe par le flux de liaison de compte.
    2. Échange un jeton d'actualisation de longue durée contre un jeton d'accès de courte durée. Cet échange se produit lorsque Google a besoin d'un nouveau jeton d'accès parce que celui qu'il avait expiré.

Choisissez un flux OAuth 2.0

Bien que le flux implicite soit plus simple à mettre en œuvre, Google recommande que les jetons d'accès émis par le flux implicite n'expirent jamais. En effet, l'utilisateur est obligé de lier à nouveau son compte après l'expiration d'un jeton avec le flux implicite. Si vous avez besoin de l'expiration du jeton pour des raisons de sécurité, nous vous recommandons vivement d'utiliser le flux de code d'autorisation à la place.

Directives de conception

Cette section décrit les exigences de conception et les recommandations pour l'écran utilisateur que vous hébergez pour les flux de liaison OAuth. Après avoir été appelée par l'application de Google, votre plate-forme affiche un écran de connexion à la page Google et un écran de consentement associant le compte à l'utilisateur. L'utilisateur est redirigé vers l'application de Google après avoir donné son accord pour associer des comptes.

Cette figure montre les étapes à suivre par un utilisateur pour associer son compte Google à votre système d'authentification. La première capture d'écran montre la liaison initié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 de l'utilisateur et la confirmation d'associer son compte Google à votre application. La capture d'écran finale montre un compte utilisateur correctement associé dans l'application Google.
Figure 1. Compte liant la connexion de l'utilisateur à Google et aux écrans d'autorisation.

Conditions

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

Recommandations

Nous vous recommandons de faire ce qui suit:

  1. Afficher la politique de confidentialité de Google. Incluez un lien vers la politique de confidentialité de Google sur l'écran de consentement.

  2. Données à partager. Utilisez un langage clair et concis pour indiquer à l'utilisateur les données dont Google a besoin et pourquoi.

  3. Incitation à l'action claire. Indiquez 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.

  4. Possibilité d'annuler. Fournissez aux utilisateurs un moyen de revenir en arrière ou d'annuler s'ils choisissent de ne pas créer de lien.

  5. Processus de connexion clair. 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 .

  6. Possibilité de dissocier. Offrez aux utilisateurs un mécanisme de dissociation, comme une URL vers les paramètres de leur compte sur votre plateforme Vous pouvez également inclure un lien vers le compte Google dans lequel les utilisateurs peuvent gérer leur compte associé.

  7. Possibilité de changer de compte utilisateur. Suggérez aux utilisateurs une méthode pour changer de compte. Ceci est particulièrement avantageux si les utilisateurs ont tendance à avoir plusieurs comptes.

    • Si un utilisateur doit fermer l'écran de consentement pour changer de compte, envoyez une erreur récupérable à Google afin que l'utilisateur puisse se connecter au compte souhaité avec la liaison OAuth et le flux implicite .
  8. Incluez votre logo. Affichez le logo de votre entreprise sur l'écran de consentement. Utilisez vos directives de style pour placer votre logo. Si vous souhaitez afficher également le logo de Google, consultez la section Logos et marques .

Configurer le projet

Pour configurer votre projet afin d'utiliser l'association de compte OAuth:

  1. Go to the Google API Console.
  2. Cliquez sur 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 Créer .

Pour afficher votre ID de projet:

  1. Go to the Google API Console.
  2. Trouvez votre projet dans le tableau de la page de destination. L'ID du projet apparaît dans la colonne ID .

Implémentez votre serveur OAuth

Une implémentation 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 déjà 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, 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.

Une session de flux de code d'autorisation OAuth 2.0 initiée par Google a le flux suivant:

  1. Google ouvre votre point de terminaison d'autorisation dans le navigateur de l'utilisateur. Si le flux a démarré sur un appareil vocal uniquement pour une action, Google transfère l'exécution sur un téléphone.
  2. L'utilisateur se connecte, s'il n'est pas déjà connecté, et autorise Google à accéder à ses données avec votre API, s'il n'a pas déjà accordé l'autorisation.
  3. Votre service crée un code d'autorisation et le renvoie à Google. Pour ce faire, redirigez le navigateur de l'utilisateur vers Google avec le code d'autorisation joint à la demande.
  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 informations d'identification pour accéder aux API. Le jeton d'actualisation est un jeton de longue durée 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 processus d'association de compte, chaque demande ultérieure envoyée par Google contient un jeton d'accès.

Gérer les demandes d'autorisation

Lorsque vous devez effectuer une association de compte à l'aide du flux de code d'autorisation OAuth 2.0, Google envoie l'utilisateur à votre point de terminaison d'autorisation avec une demande qui inclut les paramètres suivants:

Paramètres de point de terminaison d'autorisation
client_id L'ID client Google que vous avez enregistré auprès de Google.
redirect_uri L'URL à laquelle vous envoyez la réponse à cette demande.
state Une valeur comptable qui est renvoyée à Google inchangée dans l'URI de redirection.
scope Facultatif: ensemble de chaînes de champ délimitées par des espaces qui spécifient les données pour lesquelles Google demande une autorisation.
response_type Le type de valeur à renvoyer dans la réponse. Pour le flux de code d'autorisation OAuth 2.0, le type de réponse est toujours code .
user_locale Le paramètre de langue du compte Google au format RFC5646 , 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 sur https://myservice.example.com/auth , une demande peut ressembler à ce qui 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 le client_id correspond à l'ID client Google que vous avez enregistré auprès de Google et que le 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 client non intentionnelles ou mal configurées. Si vous prenez en charge plusieurs flux OAuth 2.0, confirmez également que le response_type est du code .
  2. Vérifiez si l'utilisateur est connecté à votre service. Si l'utilisateur n'est pas connecté, effectuez le processus 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 auquel le jeton est destiné et l'heure d'expiration du code, et il ne doit pas être devinable. Vous émettez généralement des codes d'autorisation qui expirent après environ 10 minutes.
  4. Confirmez que l'URL spécifiée par le paramètre 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
      
  5. Redirigez 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 le code et state paramètres d' state . Voici un exemple de l'URL résultante:
    https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

Gérer 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:

  • Échangez les codes d'autorisation pour les jetons d'accès et actualisez les jetons
  • Échanger des jetons d'actualisation pour les jetons d'accès

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

Paramètres de point de terminaison d'échange de jetons
client_id Une chaîne qui identifie l'origine de la demande en tant que Google. Cette chaîne doit être enregistrée dans votre système en tant qu'identifiant unique de Google.
client_secret Une chaîne secrète que vous avez enregistrée auprès de Google pour votre service.
grant_type Le type de jeton échangé. Il est soit authorization_code ou refresh_token .
code Lorsque grant_type=authorization_code , ce paramètre est le code que Google a reçu de votre point de terminaison de connexion ou d'échange de jetons.
redirect_uri Lorsque grant_type=authorization_code , ce paramètre est l'URL utilisée dans la demande d'autorisation initiale.
refresh_token Lorsque grant_type=refresh_token , ce paramètre est le jeton d'actualisation que Google a reçu de votre point de terminaison d'échange de jetons.
Échangez les codes d'autorisation pour les jetons d'accès et actualisez les jetons

Une fois que l'utilisateur s'est connecté et que votre point de terminaison d'autorisation a renvoyé un code d'autorisation de courte durée à Google, Google envoie une demande à 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 demandes, la valeur de grant_type est authorization_code et la valeur de code est la valeur du code d'autorisation que vous avez précédemment accordé à Google. Voici un exemple de demande d'échange d'un code d'autorisation pour 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 pour un jeton d'accès et un jeton d'actualisation, votre point de terminaison d'échange de jetons répond aux demandes POST en exécutant les étapes suivantes:

  1. Vérifiez que client_id identifie l'origine de la demande 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 demande correspond à l'ID client associé au code d'autorisation.
  3. Confirmez 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 vérifier tous les critères ci-dessus, renvoyez une erreur HTTP 400 Bad Request 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 auxquels le jeton est destiné et ils ne doivent pas être devinables. Pour les jetons d'accès, enregistrez également l'heure d'expiration du jeton, qui correspond généralement à une heure après l'émission du jeton. Les jetons d'actualisation n'expirent pas.
  6. Renvoyez 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 pour les jetons d'accès

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

Pour ces demandes, la valeur de grant_type est refresh_token et la valeur de refresh_token est la valeur du jeton d'actualisation que vous avez précédemment accordé à Google. Voici un exemple de demande d'échange d'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 demandes POST en exécutant les étapes suivantes:

  1. Vérifiez que client_id identifie l'origine de la demande comme 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 demande correspond à l'ID client associé au jeton d'actualisation.
  3. Si vous ne pouvez pas vérifier tous les critères ci-dessus, renvoyez une erreur HTTP 400 Bad Request 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 être n'importe quelle valeur de chaîne, mais ils doivent représenter de manière unique l'utilisateur et le client auxquels le jeton est destiné et ils ne doivent pas être devinables. Pour les jetons d'accès, enregistrez également l'heure d'expiration du jeton, généralement une heure après l'émission du jeton.
  5. Renvoyez l'objet JSON suivant dans le corps de la réponse HTTPS:
    {
    "token_type": "Bearer",
    "access_token": " ACCESS_TOKEN ",
    "expires_in": SECONDS_TO_EXPIRATION
    }

Rechercher un compte utilisateur existant

Une fois que l'utilisateur a donné son consentement pour accéder à son profil Google, Google envoie une demande contenant une affirmation signée de l'identité de l'utilisateur Google. L'assertion contient des informations qui incluent l'identifiant 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 demande.

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 pas à un utilisateur existant, votre point de terminaison d'échange de jetons renvoie une erreur HTTP 404 introuvable avec account_found=false .

La demande a la forme suivante:

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

Votre point de terminaison d'échange de jetons doit être capable de gérer les paramètres suivants:

Paramètres de point de terminaison de jeton
intent Pour ces demandes, la valeur de ce paramètre est check .
grant_type Le type de jeton échangé. Pour ces requêtes, ce paramètre a la valeur urn:ietf:params:oauth:grant-type:jwt-bearer .
assertion Un jeton Web JSON (JWT) qui fournit une assertion signée de l'identité de l'utilisateur Google. Le JWT contient des informations qui incluent l'ID de compte Google, le nom et l'adresse e-mail de l'utilisateur.

Lorsque votre point de terminaison d'échange de jetons reçoit la demande de check , il doit valider et décoder l'assertion JWT.

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 et hd 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, trouvé dans le sub champ de l'assertion, se trouve dans votre base de données d'utilisateurs.
  • L'adresse e-mail dans l'assertion correspond à un utilisateur dans votre base de données d'utilisateurs.

Si l'une ou l'autre des conditions est vraie, l'utilisateur s'est déjà inscrit. Dans ce cas, renvoyez une réponse comme celle-ci:

HTTP/1.1 200 Success
Content-Type: application/json;charset=UTF-8

{
  "account_found":"true",
}

Google affiche ensuite une boîte de dialogue de consentement de liaison à l'utilisateur et demande son consentement pour les portées souhaitées afin de continuer la liaison. Une fois que Google a get le consentement de l'utilisateur, Google envoie une demande d' get à votre point de terminaison de jeton pour poursuivre la liaison.

Si ni l'ID de compte Google ni l'adresse e-mail spécifiés dans l'assertion ne correspondent à un utilisateur de votre base de données, l'utilisateur ne s'est pas encore inscrit. Dans ce cas, votre point de terminaison d'échange de jetons doit répondre avec une erreur HTTP 404 qui spécifie "account_found": "false" , comme dans l'exemple suivant:

HTTP/1.1 404 Not found
Content-Type: application/json;charset=UTF-8

{
  "account_found":"false",
}
Lorsque Google reçoit la réponse d'erreur 404 avec une erreur "account_found": "false" , Google affiche une boîte de dialogue à l'utilisateur pour demander son consentement pour créer un nouveau compte et accéder aux portées souhaitées. Une fois que Google a obtenu le consentement de l'utilisateur, Google appelle votre point de terminaison d'échange de jetons avec la valeur du paramètre d' intent défini à create et inclut un jeton d'identification contenant les informations de profil de l'utilisateur avec la demande.

Gérer la liaison automatique

Une fois que l'utilisateur a donné son consentement pour accéder à son profil Google, Google envoie une demande contenant une affirmation signée de l'identité de l'utilisateur Google. L'assertion contient des informations qui incluent l'identifiant 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 demande.

Si le compte Google correspondant est déjà présent dans votre système d'authentification, votre point de terminaison d'échange de jetons renvoie un jeton pour l'utilisateur. Si le compte Google ne correspond pas à un utilisateur existant, votre point de terminaison d'échange de jetons renvoie une erreur de linking_error et facultatif login_hint .

La demande a la forme suivante:

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

Votre point de terminaison d'échange de jetons doit être capable de gérer les paramètres suivants:

Paramètres de point de terminaison de jeton
intent Pour ces requêtes, la valeur de ce paramètre est get .
grant_type Le type de jeton échangé. Pour ces requêtes, ce paramètre a la valeur urn:ietf:params:oauth:grant-type:jwt-bearer .
assertion Un jeton Web JSON (JWT) qui fournit une assertion signée de l'identité de l'utilisateur Google. Le JWT contient des informations qui incluent l'ID de compte Google, le nom et l'adresse e-mail de l'utilisateur.
scope Facultatif: tout champ d'application que vous avez configuré Google pour demander aux utilisateurs.

Lorsque votre point de terminaison d'échange de jetons reçoit la demande de liaison, il doit valider et décoder l'assertion JWT.

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 et hd 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, trouvé dans le sub champ de l'assertion, se trouve dans votre base de données d'utilisateurs.
  • L'adresse e-mail dans l'assertion correspond à un utilisateur dans votre base de données d'utilisateurs.

Dans certains cas, la liaison de compte basée sur un jeton d'identification peut échouer pour l'utilisateur. Si c'est le cas pour une raison quelconque, votre point de terminaison d'échange de jetons doit répondre avec une erreur HTTP 401 qui spécifie error=linking_error , comme le montre l'exemple suivant:

HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=UTF-8

{
  "error":"linking_error",
  "login_hint":"foo@bar.com"
}
Lorsque Google reçoit une réponse d'erreur 401 avec linking_error , Google appelle votre point de terminaison d'échange de jetons avec ce qui suit dans la demande:

  • Le jeu de paramètres d' intent à create
  • Un JWT avec le jeton d'identification et les informations de profil de l'utilisateur

Gérez la création de compte via Google Sign-In

Lorsqu'un utilisateur doit créer un compte sur votre service, Google envoie une demande à votre point de terminaison d'échange de jetons qui spécifie intent=create .

La demande a la forme suivante:

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[&NEW_ACCOUNT_INFO]

Votre point de terminaison d'échange de jetons doit pouvoir gérer les paramètres suivants:

Paramètres de point de terminaison de jeton
intent Pour ces demandes, la valeur de ce paramètre est create .
grant_type Le type de jeton échangé. Pour ces requêtes, ce paramètre a la valeur urn:ietf:params:oauth:grant-type:jwt-bearer .
assertion Un jeton Web JSON (JWT) qui fournit une assertion signée de l'identité de l'utilisateur Google. Le JWT contient des informations qui incluent l'ID de compte Google, le nom et l'adresse e-mail de l'utilisateur.

Le JWT dans le paramètre d' assertion contient l'ID de compte Google, le nom et l'adresse e-mail de l'utilisateur, que vous pouvez utiliser pour créer un nouveau compte sur votre service.

Pour répondre aux demandes de création de compte, votre point de terminaison d'échange de jetons doit effectuer les étapes des deux sections suivantes.

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 et hd 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.

Validez les informations utilisateur et créez un nouveau compte

Vérifiez si l'une des conditions suivantes est remplie:

  • L'ID de compte Google, trouvé dans le sub champ de l'assertion, se trouve dans votre base de données d'utilisateurs.
  • L'adresse e-mail dans l'assertion correspond à un utilisateur dans votre base de données d'utilisateurs.

Si l'une ou l'autre de ces conditions est remplie, invitez l'utilisateur à associer son compte existant à son compte Google. Pour ce faire, répondez à la demande avec une erreur HTTP 401 qui spécifie error=linking_error et donne l'adresse e-mail de l'utilisateur comme login_hint . Voici un exemple de réponse:

HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=UTF-8

{
  "error":"linking_error",
  "login_hint":"foo@bar.com"
}

Lorsque Google reçoit une réponse d'erreur 401 avec linking_error , Google envoie l'utilisateur à votre point de terminaison d'autorisation avec login_hint comme paramètre. L'utilisateur termine la liaison du compte à l'aide du flux de liaison OAuth dans son navigateur.

Si aucune condition n'est vraie, créez un nouveau compte utilisateur avec les informations fournies dans le JWT. Les nouveaux comptes n'ont généralement pas de mot de passe défini. Il est recommandé d'ajouter Google Sign-In à d'autres plates-formes pour permettre aux utilisateurs de se connecter avec Google sur toutes les surfaces de votre application. Vous pouvez également envoyer par e-mail à l'utilisateur un lien qui démarre votre flux de récupération de mot de passe pour lui permettre de définir un mot de passe pour se connecter sur d'autres plates-formes.

Lorsque la création est terminée, émettez un jeton d'accès et actualisez le jeton et renvoyez les valeurs dans un objet JSON dans le corps de votre réponse HTTPS, comme dans l'exemple suivant:

{
  "token_type": "Bearer",
  "access_token": "ACCESS_TOKEN",

  "refresh_token": "REFRESH_TOKEN",

  "expires_in": SECONDS_TO_EXPIRATION
}

Valider votre implémentation

Vous pouvez valider votre implémentation à l'aide de l'outil OAuth 2.0 Playground .

Dans l'outil, procédez comme suit:

  1. Cliquez sur Paramètres de pour ouvrir la fenêtre de configuration OAuth 2.0.
  2. Dans le champ de flux OAuth , sélectionnez Côté client .
  3. Dans le champ OAuth Endpoints , sélectionnez Personnalisé .
  4. Spécifiez votre point de terminaison OAuth 2.0 et l'ID client que vous avez attribué à Google dans les champs correspondants.
  5. Dans la section Étape 1 , ne sélectionnez aucun champ d'application 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 .
  6. Dans les sections Étape 2 et Étape 3 , parcourez le flux OAuth 2.0 et vérifiez que chaque étape fonctionne comme prévu.

Vous pouvez valider votre mise en œuvre à l'aide de l'outil de démonstration d'association de compte Google .

Dans l'outil, procédez comme suit:

  1. Cliquez sur le bouton Se connecter avec Google .
  2. Choisissez le compte que vous souhaitez associer.
  3. Saisissez l'ID de service.
  4. Entrez éventuellement une ou plusieurs étendues pour lesquelles vous demanderez l'accès.
  5. Cliquez sur Démarrer la démo .
  6. Lorsque vous y êtes invité, confirmez que vous pouvez consentir et refuser la demande d'association.
  7. Confirmez que vous êtes redirigé vers votre plateforme.