OpenID Connect

Les API OAuth 2.0 de Google peuvent être utilisées à la fois pour l'authentification et l'autorisation. Ce document décrit notre mise en œuvre d'authentification OAuth 2.0, qui est conforme à la spécification OpenID Connect et certifiée OpenID. La documentation disponible sur la page Utiliser OAuth 2.0 pour accéder aux API Google s'applique également à ce service. Si vous souhaitez explorer ce protocole de manière interactive, nous vous recommandons Google OAuth 2.0 Playground. Pour obtenir de l'aide sur Stack Overflow, ajoutez le tag "google-oauth" à vos questions.

Configurer OAuth 2.0

Pour que votre application puisse utiliser le système d'authentification OAuth 2.0 de Google pour la connexion utilisateur, vous devez configurer un projet dans Google API Console afin d'obtenir les identifiants OAuth 2.0, définir un URI de redirection et (éventuellement) personnaliser les informations de marque visibles par vos utilisateurs sur l'écran d'autorisation des utilisateurs. Vous pouvez également utiliser API Console pour créer un compte de service, activer la facturation, configurer le filtrage et effectuer d'autres tâches. Pour en savoir plus, consultez l'aideGoogle API Console.

Obtenir des identifiants OAuth 2.0

Vous avez besoin d'identifiants OAuth 2.0, y compris un ID et un code secret de client, pour authentifier les utilisateurs et accéder aux API Google.

Pour afficher l'ID client et le secret client pour une information d'identification OAuth 2.0 donnée, cliquez sur le texte suivant: Sélectionnez les informations d'identification . Dans la fenêtre qui s'ouvre, choisissez votre projet et les informations d'identification souhaitées, puis cliquez sur Afficher .

Ou affichez votre ID client et votre secret client sur la page API Console identification dans API Console :

1. Go to the Credentials page.
2. Cliquez sur le nom de vos informations d'identification ou sur l'icône en forme de crayon ( create ). Votre identifiant client et votre secret sont en haut de la page.

Définir un URI de redirection

L'URI de redirection que vous définissez dans API Console détermine l'endroit où Google envoie les réponses à vos requêtes d'authentification.

Pour créer, afficher ou modifier les URI de redirection pour une information d'identification OAuth 2.0 donnée, procédez comme suit:

1. Go to the Credentials page.
2. Dans la section ID client OAuth 2.0 de la page, cliquez sur une information d'identification.
3. Affichez ou modifiez les URI de redirection.

S'il n'y a pas de section ID client OAuth 2.0 sur la page Informations d'identification, votre projet n'a pas d'informations d'identification OAuth. Pour en créer un, cliquez sur Créer des informations d'identification .

Personnaliser l'écran de consentement de l'utilisateur

Pour vos utilisateurs, l'expérience d'authentification OAuth 2.0 inclut un écran d'autorisation qui décrit les informations qu'il libère et les conditions qui s'appliquent. Par exemple, lorsque l'utilisateur se connecte, il peut être invité à donner à votre application l'accès à son adresse e-mail et aux informations de base de son compte. Vous demandez l'accès à ces informations à l'aide du paramètre scope, que votre appli inclut dans sa requête d'authentification. Vous pouvez également utiliser des champs d'application pour demander l'accès à d'autres API Google.

L'écran de consentement de l'utilisateur présente également des informations sur le branding, telles que le nom de votre produit, votre logo et l'URL de la page d'accueil. Vous contrôlez les informations de branding dans API Console.

Pour activer l'écran de consentement de votre projet:

1. Ouvrez le Consent Screen page dans le Google API Console .
2. If prompted, select a project, or create a new one.
3. Remplissez le formulaire et cliquez sur Enregistrer .

La boîte de dialogue de collecte du consentement qui s'affiche montre ce qu'un utilisateur peut voir en combinant les champs d'application OAuth 2.0 et Google Drive à sa requête. Étant donné que cette boîte de dialogue générique a été générée à l'aide de Google OAuth 2.0 Playground, elle n'inclut pas les informations de branding définies dans API Console.

Accéder au service

Google et des tiers fournissent des bibliothèques qui vous permettent de vous occuper de la plupart des détails de la mise en œuvre de l'authentification des utilisateurs et de l'accès aux API Google. Exemples : Google Identity Services et les bibliothèques clientes Google, disponibles pour diverses plates-formes.

Si vous choisissez de ne pas utiliser de bibliothèque, suivez les instructions dans le reste de ce document, qui décrit les flux de requêtes HTTP qui sous-tendent les bibliothèques disponibles.

Authentifier l'utilisateur

Pour authentifier l'utilisateur, vous devez obtenir un jeton d'ID et le valider. Les jetons d'identification sont une fonctionnalité normalisée d'OpenID Connect, conçue pour partager des assertions sur Internet.

Les approches les plus couramment utilisées pour authentifier un utilisateur et obtenir un jeton d'ID sont les flux "serveur" et "implicite". Le flux du serveur permet au serveur backend d'une application de vérifier l'identité de la personne via un navigateur ou un appareil mobile. Le flux implicite est utilisé lorsqu'une application côté client (généralement une application JavaScript exécutée dans le navigateur) doit accéder directement aux API plutôt que via son serveur backend.

Ce document explique comment effectuer le flux de serveurs pour authentifier l'utilisateur. Le flux implicite est beaucoup plus complexe en raison des risques de sécurité dans le traitement et l'utilisation de jetons côté client. Si vous devez mettre en œuvre un flux implicite, nous vous recommandons vivement d'utiliser les services Google Identity.

Flux du serveur

Assurez-vous de configurer votre application dans le API Console pour qu'elle puisse utiliser ces protocoles et authentifier vos utilisateurs. Lorsqu'un utilisateur tente de se connecter avec Google, vous devez:

1. Créer un jeton d'état anti-falsification
2. Envoyer une demande d'authentification à Google
3. Confirmer le jeton d'état contre les contrefaçons
4. Échanger code contre un jeton d'accès et un jeton d'ID
5. Obtenir des informations sur l'utilisateur à partir du jeton d'ID
6. Authentifier l'utilisateur

1. Créer un jeton d'état anti-falsification

Vous devez protéger la sécurité de vos utilisateurs en empêchant les attaques par falsification des requêtes. La première étape consiste à créer un jeton de session unique qui maintient l'état entre votre application et le client de l'utilisateur. Vous faites ensuite correspondre ce jeton de session unique à la réponse d'authentification renvoyée par le service Google OAuth Login afin de vérifier que l'utilisateur effectue la requête et non un pirate malveillant. Ces jetons sont souvent appelés "jetons de falsification de requêtes intersites" (CSRF).

Un jeton d'état adapté est une chaîne de 30 caractères environ créée à l'aide d'un générateur de nombres aléatoires de haute qualité. Un hachage est également généré en signant certaines de vos variables d'état de session avec une clé gardée secrète dans le backend.

Le code suivant montre comment générer des jetons de session uniques.

// Create a state token to prevent request forgery.
// Store it in the session for later validation.
$state = bin2hex(random_bytes(128/8));
$app['session']->set('state', $state);
// Set the client ID, token state, and application name in the HTML while
// serving it.
return $app['twig']->render('index.html', array(
    'CLIENT_ID' => CLIENT_ID,
    'STATE' => $state,
    'APPLICATION_NAME' => APPLICATION_NAME
));

// Create a state token to prevent request forgery.
// Store it in the session for later validation.
String state = new BigInteger(130, new SecureRandom()).toString(32);
request.session().attribute("state", state);
// Read index.html into memory, and set the client ID,
// token state, and application name in the HTML before serving it.
return new Scanner(new File("index.html"), "UTF-8")
    .useDelimiter("\\A").next()
    .replaceAll("[{]{2}\\s*CLIENT_ID\\s*[}]{2}", CLIENT_ID)
    .replaceAll("[{]{2}\\s*STATE\\s*[}]{2}", state)
    .replaceAll("[{]{2}\\s*APPLICATION_NAME\\s*[}]{2}",
    APPLICATION_NAME);

# Create a state token to prevent request forgery.
# Store it in the session for later validation.
state = hashlib.sha256(os.urandom(1024)).hexdigest()
session['state'] = state
# Set the client ID, token state, and application name in the HTML while
# serving it.
response = make_response(
    render_template('index.html',
                    CLIENT_ID=CLIENT_ID,
                    STATE=state,
                    APPLICATION_NAME=APPLICATION_NAME))

2. Envoyer une demande d'authentification à Google

L'étape suivante consiste à former une requête HTTPS GET avec les paramètres d'URI appropriés. Notez l'utilisation de HTTPS plutôt que HTTP dans toutes les étapes de ce processus. Les connexions HTTP sont refusées. Vous devez récupérer l'URI de base du document de découverte à l'aide de la valeur de métadonnées authorization_endpoint. La discussion suivante suppose que l'URI de base est https://accounts.google.com/o/oauth2/v2/auth.

Pour une requête de base, spécifiez les paramètres suivants:

• client_id, que vous obtenez à partir de API ConsoleCredentials page.
• response_type, qui, dans une requête de flux de code d'autorisation de base, doit être code. Pour en savoir plus, consultez response_type.
• scope, qui doit être openid email dans une requête de base. Pour en savoir plus, consultez scope.
• redirect_uri doit être le point de terminaison HTTP de votre serveur qui recevra la réponse de Google. La valeur doit correspondre exactement à l'un des URI de redirection autorisés pour le client OAuth 2.0, que vous avez configuré dans API ConsoleCredentials page. Si cette valeur ne correspond pas à un URI autorisé, la requête échoue et renvoie une erreur redirect_uri_mismatch.
• state doit inclure la valeur du jeton de session unique contre les contrefaçons, ainsi que toute autre information requise pour récupérer le contexte lorsque l'utilisateur revient dans votre application, par exemple l'URL de démarrage. Pour en savoir plus, consultez state.
• nonce est une valeur aléatoire générée par votre application qui active la protection contre les répétitions lorsqu'elle est présente.
• login_hint peut être l'adresse e-mail de l'utilisateur ou la chaîne sub, qui est équivalente à l'ID Google de l'utilisateur. Si vous ne fournissez pas de login_hint et que l'utilisateur est actuellement connecté, l'écran d'autorisation inclut une demande d'approbation pour libérer l'adresse e-mail de l'utilisateur dans votre application. (Pour en savoir plus, consultez login_hint.)
• Utilisez le paramètre hd pour optimiser le flux OpenID Connect pour les utilisateurs d'un domaine particulier associé à une organisation Google Cloud. Pour en savoir plus, consultez hd.

Voici un exemple d'URI d'authentification OpenID Connect complet, avec des sauts de ligne et des espaces pour la lisibilité:

https://accounts.google.com/o/oauth2/v2/auth?
 response_type=code&
 client_id=424911365001.apps.googleusercontent.com&
 scope=openid%20email&
 redirect_uri=https%3A//oauth2.example.com/code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2-login-demo.example.com%2FmyHome&
 login_hint=jsmith@example.com&
 nonce=0394852-3190485-2490358&
 hd=example.com

Les utilisateurs doivent donner leur autorisation si votre appli demande de nouvelles informations les concernant, ou si votre appli demande l'accès au compte qu'elle n'a pas déjà approuvée.

3. Confirmer le jeton d'état contre la falsification

La réponse est envoyée au redirect_uri que vous avez spécifié dans la requête. Toutes les réponses sont renvoyées dans la chaîne de requête, comme indiqué ci-dessous:

https://oauth2.example.com/code?state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foa2cb.example.com%2FmyHome&code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&scope=openid%20email%20https://www.googleapis.com/auth/userinfo.email

Sur le serveur, vous devez confirmer que le state reçu de Google correspond au jeton de session que vous avez créé à l'étape 1. Cette vérification aller-retour permet de s'assurer que l'utilisateur effectue la requête, et non un script malveillant.

Le code suivant montre la confirmation des jetons de session que vous avez créés à l'étape 1:

// Ensure that there is no request forgery going on, and that the user
// sending us this connect request is the user that was supposed to.
if ($request->get('state') != ($app['session']->get('state'))) {
  return new Response('Invalid state parameter', 401);
}

// Ensure that there is no request forgery going on, and that the user
// sending us this connect request is the user that was supposed to.
if (!request.queryParams("state").equals(
    request.session().attribute("state"))) {
  response.status(401);
  return GSON.toJson("Invalid state parameter.");
}

# Ensure that the request is not a forgery and that the user sending
# this connect request is the expected user.
if request.args.get('state', '') != session['state']:
  response = make_response(json.dumps('Invalid state parameter.'), 401)
  response.headers['Content-Type'] = 'application/json'
  return response

4. Remplacement de code par le jeton d'accès et le jeton d'ID

La réponse inclut un paramètre code, un code d'autorisation unique que votre serveur peut échanger contre un jeton d'accès et un jeton d'identification. Votre serveur effectue cet échange en envoyant une requête HTTPS POST. La requête POST est envoyée au point de terminaison du jeton, que vous devez récupérer à partir du document de découverte à l'aide de la valeur de métadonnées token_endpoint. La discussion suivante suppose que le point de terminaison est https://oauth2.googleapis.com/token. La requête doit inclure les paramètres suivants dans le corps POST:

La requête réelle peut se présenter comme suit:

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

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your-client-id&
client_secret=your-client-secret&
redirect_uri=https%3A//oauth2.example.com/code&
grant_type=authorization_code

Une réponse positive à cette requête contient les champs suivants dans un tableau JSON:

5. Obtenir des informations sur l'utilisateur à partir du jeton d'ID

Un jeton d'ID est un jeton Web JSON (JWT), c'est-à-dire un objet JSON encodé au format Base64 et chiffré. Normalement, il est essentiel de valider un jeton d'ID avant de l'utiliser. Toutefois, comme vous communiquez directement avec Google via un canal HTTPS sans intermédiaire et que vous utilisez votre code secret client pour vous authentifier auprès de Google, vous pouvez être sûr que le jeton que vous recevez provient bien de Google et qu'il est valide. Si votre serveur transmet le jeton d'ID à d'autres composants de votre application, il est extrêmement important que les autres composants valident le jeton avant de l'utiliser.

Étant donné que la plupart des bibliothèques d'API associent la validation au travail de décodage des valeurs encodées en base64url et à l'analyse du fichier JSON, vous finirez probablement par valider le jeton lorsque vous accéderez aux revendications du jeton d'ID.

Charge utile d'un jeton d'ID

Un jeton d'ID est un objet JSON contenant un ensemble de paires nom/valeur. Voici un exemple mis en forme pour une meilleure lisibilité:

{
  "iss": "https://accounts.google.com",
  "azp": "1234987819200.apps.googleusercontent.com",
  "aud": "1234987819200.apps.googleusercontent.com",
  "sub": "10769150350006150715113082367",
  "at_hash": "HK6E_P6Dh8Y93mRNtsDB1Q",
  "hd": "example.com",
  "email": "jsmith@example.com",
  "email_verified": "true",
  "iat": 1353601026,
  "exp": 1353604926,
  "nonce": "0394852-3190485-2490358"
}

Les jetons d'ID Google peuvent contenir les champs suivants (appelés revendications):

6. Authentifier l'utilisateur

Après avoir obtenu les informations utilisateur à partir du jeton d'ID, vous devez interroger la base de données utilisateur de votre application. Si l'utilisateur existe déjà dans votre base de données, vous devez démarrer une session d'application pour cet utilisateur si toutes les conditions de connexion sont remplies par la réponse de l'API Google.

Si l'utilisateur n'existe pas dans votre base de données utilisateur, vous devez le rediriger vers votre parcours d'inscription pour les nouveaux utilisateurs. Vous pourrez peut-être enregistrer automatiquement l'utilisateur en fonction des informations que vous recevez de Google ou, au moins, vous pourrez renseigner la plupart des champs requis dans votre formulaire d'inscription. En plus des informations contenues dans le jeton d'ID, vous pouvez obtenir des informations supplémentaires sur le profil utilisateur aux points de terminaison de ce profil.

Rubriques avancées

Les sections suivantes décrivent l'API Google OAuth 2.0 plus en détail. Ces informations sont destinées aux développeurs ayant des exigences avancées concernant l'authentification et l'autorisation.

Accès à d'autres API Google

L'un des avantages de l'authentification OAuth 2.0 est que votre application peut obtenir l'autorisation d'utiliser d'autres API Google pour le compte de l'utilisateur (YouTube, Google Drive, Agenda ou Contacts, par exemple) en même temps que vous authentifiez l'utilisateur. Pour ce faire, incluez les autres champs d'application dont vous avez besoin dans la requête d'authentification que vous envoyez à Google. Par exemple, pour ajouter la tranche d'âge de l'utilisateur à votre requête d'authentification, transmettez un paramètre de champ d'application défini sur openid email https://www.googleapis.com/auth/profile.agerange.read. L'utilisateur y est invité de manière appropriée sur l'écran d'autorisation. Le jeton d'accès que vous recevez de la part de Google vous permet d'accéder à toutes les API associées aux champs d'application d'accès que vous avez demandés et accordés.

Jetons d'actualisation

Dans votre demande d'accès à l'API, vous pouvez demander qu'un jeton d'actualisation soit renvoyé lors de l'échange code. Un jeton d'actualisation fournit à votre application un accès continu aux API Google lorsque l'utilisateur n'est pas présent dans votre application. Pour demander un jeton d'actualisation, ajoutez le paramètre access_type à offline dans votre requête d'authentification.

Remarques importantes :

• Veillez à stocker le jeton d'actualisation de manière sécurisée et permanente. En effet, vous ne pouvez obtenir un jeton d'actualisation que la première fois que vous exécutez le flux d'échange de code.
• Le nombre de jetons d'actualisation émis est limité: une limite par combinaison client/utilisateur et une autre par utilisateur pour tous les clients. Si votre application demande trop de jetons d'actualisation, elle peut atteindre ces limites, auquel cas les anciens jetons d'actualisation ne fonctionneront plus.

Pour en savoir plus, consultez Actualiser un jeton d'accès (accès hors connexion).

Demander à nouveau le consentement

Vous pouvez inviter l'utilisateur à réautoriser votre application en définissant le paramètre prompt sur consent dans votre requête d'authentification. Lorsque prompt=consent est inclus, l'écran d'autorisation s'affiche chaque fois que votre application demande une autorisation pour les niveaux d'accès, même si tous les champs d'application ont été précédemment accordés à votre projet d'API Google. Pour cette raison, n'incluez prompt=consent que si nécessaire.

Pour en savoir plus sur le paramètre prompt, consultez la section prompt du tableau Paramètres d'URI d'authentification.

Paramètres URI d'authentification

Le tableau suivant fournit une description plus complète des paramètres acceptés par l'API OAuth 2.0 d'authentification de Google.

Valider un jeton d'ID

Vous devez valider tous les jetons d'identification sur votre serveur, sauf si vous savez qu'ils proviennent directement de Google. Par exemple, votre serveur doit vérifier comme authentique tous les jetons d'ID qu'il reçoit de vos applications clientes.

Voici des situations courantes dans lesquelles vous pouvez envoyer des jetons d'identification à votre serveur:

• Envoyer des jetons d'identification avec des requêtes à authentifier Les jetons d'ID vous indiquent l'utilisateur à l'origine de la requête et pour quel client ce jeton a été accordé.

Les jetons d'identification sont sensibles et peuvent être utilisés de manière abusive interceptés. Vous devez vous assurer que ces jetons sont gérés de manière sécurisée en ne les transmettant que via HTTPS et uniquement via des données POST ou dans des en-têtes de requête. Si vous stockez des jetons d'identification sur votre serveur, vous devez également les stocker de manière sécurisée.

Les jetons d'identification sont utiles, car ils peuvent être transmis entre différents composants de votre application. Ces composants peuvent utiliser un jeton d'ID comme mécanisme d'authentification léger authentifiant l'application et l'utilisateur. Toutefois, vous devez les valider avant de pouvoir utiliser les informations du jeton d'ID ou de les utiliser comme une assertion que l'utilisateur a authentifié.

La validation d'un jeton d'identification nécessite plusieurs étapes:

1. Vérifiez que le jeton d'ID est correctement signé par l'émetteur. Les jetons émis par Google sont signés à l'aide de l'un des certificats disponibles dans l'URI spécifiée dans la valeur de métadonnées jwks_uri du document de découverte.
2. Vérifiez que la valeur de la revendication iss dans le jeton d'ID est égale à https://accounts.google.com ou accounts.google.com.
3. Vérifiez que la valeur de la revendication aud dans le jeton d'ID est égale à l'ID client de votre application.
4. Vérifiez que le délai d'expiration (revendication exp) du jeton d'ID n'a pas été dépassé.
5. Si vous avez spécifié une valeur pour le paramètre hd dans la requête, vérifiez que le jeton d'ID possède une revendication hd qui correspond à un domaine accepté associé à une organisation Google Cloud.

Les étapes 2 à 5 n'impliquent que des comparaisons de chaînes et de dates très simples. Nous ne les détaillerons donc pas ici.

La première étape est plus complexe et implique une vérification des signatures cryptographiques. À des fins de débogage, vous pouvez utiliser le point de terminaison tokeninfo de Google pour comparer le traitement local mis en œuvre sur votre serveur ou votre appareil. Supposons que la valeur de votre jeton d'ID soit XYZ123. Vous devez ensuite déréférencer l'URI https://oauth2.googleapis.com/tokeninfo?id_token=XYZ123. Si la signature du jeton est valide, la réponse correspond à la charge utile JWT sous sa forme d'objet JSON décodée.

Le point de terminaison tokeninfo est utile pour le débogage, mais à des fins de production, récupérez les clés publiques de Google à partir du point de terminaison des clés et effectuez la validation localement. Vous devez récupérer l'URI des clés du document de découverte à l'aide de la valeur de métadonnées jwks_uri. Les requêtes envoyées au point de terminaison de débogage peuvent être limitées ou faire l'objet d'erreurs intermittentes.

Comme Google ne modifie que rarement ses clés publiques, vous pouvez les mettre en cache à l'aide des instructions de cache de la réponse HTTP et, dans la grande majorité des cas, effectuer une validation locale bien plus efficacement qu'avec le point de terminaison tokeninfo. Cette validation nécessite de récupérer et d'analyser les certificats, et d'effectuer les appels de chiffrement appropriés pour vérifier la signature. Heureusement, il existe des bibliothèques bien déboguers dans une grande variété de langages (voir jwt.io).

Obtenir des informations de profil utilisateur

Pour obtenir des informations de profil supplémentaires sur l'utilisateur, vous pouvez utiliser le jeton d'accès (que votre application reçoit lors du flux d'authentification) et la norme OpenID Connect:

1. Pour être conforme à OpenID, vous devez inclure les valeurs de champ d'application openid profile dans votre requête d'authentification.

   Si vous souhaitez inclure l'adresse e-mail de l'utilisateur, vous pouvez spécifier une valeur de champ d'application supplémentaire de email. Pour spécifier profile et email, vous pouvez inclure le paramètre suivant dans l'URI de votre requête d'authentification:

   scope=openid%20profile%20email

2. Ajoutez votre jeton d'accès à l'en-tête d'autorisation et envoyez une requête HTTPS GET au point de terminaison userinfo, que vous devez récupérer à partir du document de découverte à l'aide de la valeur de métadonnées userinfo_endpoint. La réponse userinfo inclut des informations sur l'utilisateur, comme décrit dans OpenID Connect Standard Claims et la valeur de métadonnées claims_supported du document Discovery. Les utilisateurs ou leurs organisations peuvent choisir de fournir ou de ne pas conserver certains champs. Il est donc possible que vous ne receviez pas d'informations pour chaque champ pour vos niveaux d'accès autorisés.

Document Discovery

Le protocole OpenID Connect nécessite l'utilisation de plusieurs points de terminaison pour authentifier les utilisateurs et pour demander des ressources, y compris des jetons, des informations utilisateur et des clés publiques.

Pour simplifier les implémentations et accroître la flexibilité, OpenID Connect permet d'utiliser un document de découverte, un document JSON qui se trouve à un emplacement connu et contenant des paires clé/valeur fournissant des informations sur la configuration du fournisseur OpenID Connect, y compris les URI des points de terminaison d'autorisation, de jeton, de révocation, d'informations sur l'utilisateur et de clé publique. Le document Discovery pour le service OpenID Connect de Google peut être récupéré:

https://accounts.google.com/.well-known/openid-configuration

Pour utiliser les services OpenID Connect de Google, vous devez coder en dur l'URI du document Discovery (https://accounts.google.com/.well-known/openid-configuration) dans votre application. Votre application récupère le document, applique des règles de mise en cache dans la réponse, puis en extrait les URI de point de terminaison si nécessaire. Par exemple, pour authentifier un utilisateur, votre code récupère la valeur de métadonnées authorization_endpoint (https://accounts.google.com/o/oauth2/v2/auth dans l'exemple ci-dessous) comme URI de base pour les requêtes d'authentification envoyées à Google.

Voici un exemple de ce type de document. Les noms des champs sont ceux spécifiés dans OpenID Connect Discovery 1.0 (pour connaître leur signification, consultez ce document). Les valeurs sont uniquement fournies à titre d'illustration et peuvent changer, même si elles sont copiées à partir d'une version récente du document Google Discovery.

{
  "issuer": "https://accounts.google.com",
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
  "token_endpoint": "https://oauth2.googleapis.com/token",
  "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
  "revocation_endpoint": "https://oauth2.googleapis.com/revoke",
  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
  "response_types_supported": [
    "code",
    "token",
    "id_token",
    "code token",
    "code id_token",
    "token id_token",
    "code token id_token",
    "none"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "scopes_supported": [
    "openid",
    "email",
    "profile"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_post",
    "client_secret_basic"
  ],
  "claims_supported": [
    "aud",
    "email",
    "email_verified",
    "exp",
    "family_name",
    "given_name",
    "iat",
    "iss",
    "locale",
    "name",
    "picture",
    "sub"
  ],
  "code_challenge_methods_supported": [
    "plain",
    "S256"
  ]
}

Vous pouvez peut-être éviter un aller-retour HTTP en mettant en cache les valeurs du document de découverte. Les en-têtes de mise en cache HTTP standards sont utilisés et doivent être respectés.

Bibliothèques clientes

Les bibliothèques clientes suivantes facilitent l'implémentation d'OAuth 2.0 en intégrant les frameworks les plus courants:

• Bibliothèque cliente des API Google pour Java
• Bibliothèque cliente des API Google pour Python
• Bibliothèque cliente des API Google pour .NET
• Bibliothèque cliente des API Google pour Ruby
• Bibliothèque cliente des API Google pour PHP
• Bibliothèque OAuth 2.0 pour Google Web Toolkit
• Boîtes à outils Google pour les contrôleurs OAuth 2.0 Mac

Conformité OpenID Connect

Le système d'authentification OAuth 2.0 de Google est compatible avec les fonctionnalités requises pour la spécification OpenID Connect Core. Tout client conçu pour fonctionner avec OpenID Connect doit interagir avec ce service (à l'exception de l'objet de requête OpenID).