Ce document explique comment les applications de serveur Web utilisent les bibliothèques clientes des API Google ou les points de terminaison Google OAuth 2.0 pour mettre en œuvre l'autorisation OAuth 2.0 permettant d'accéder à l'API YouTube Data.
OAuth 2.0 permet aux utilisateurs de partager des données spécifiques avec une application tout en préservant la confidentialité de leurs noms d'utilisateur, mots de passe et autres informations. Par exemple, une application peut utiliser OAuth 2.0 pour obtenir l'autorisation de récupérer les données YouTube d'une chaîne.
Ce flux OAuth 2.0 est spécifiquement destiné à l'autorisation de l'utilisateur. Il est conçu pour les applications pouvant stocker des informations confidentielles et gérer l'état. Une application de serveur Web correctement autorisée peut accéder à une API pendant que l'utilisateur interagit avec l'application ou après qu'il a quitté l'application.
Les applications de serveur Web utilisent souvent également des comptes de service pour autoriser des requêtes API, en particulier lorsque vous appelez des API Cloud pour accéder à des données basées sur des projets plutôt qu'à des données spécifiques à l'utilisateur. Les applications de serveur Web peuvent utiliser les comptes de service conjointement avec l'autorisation utilisateur.
L'API YouTube Live Streaming n'est pas compatible avec le flux du compte de service. Étant donné qu'il n'existe aucun moyen d'associer un compte de service à un compte YouTube, toute tentative d'autorisation des requêtes avec ce flux générera une erreur NoLinkedYouTubeAccount
.
Bibliothèques clientes
Les exemples propres au langage présentés sur cette page utilisent les bibliothèques clientes des API Google pour mettre en œuvre l'autorisation OAuth 2.0. Pour exécuter les exemples de code, vous devez d'abord installer la bibliothèque cliente pour votre langage.
Lorsque vous utilisez une bibliothèque cliente des API Google pour gérer le flux OAuth 2.0 de votre application, celle-ci effectue de nombreuses actions que l'application devrait normalement gérer elle-même. Par exemple, elle détermine à quel moment l'application peut utiliser ou actualiser les jetons d'accès stockés, ainsi que le moment où l'application doit de nouveau obtenir le consentement. La bibliothèque cliente génère également des URL de redirection correctes et aide à mettre en œuvre des gestionnaires de redirection qui échangent des codes d'autorisation contre des jetons d'accès.
Les bibliothèques clientes des API Google pour les applications côté serveur sont disponibles dans les langages suivants:
Conditions préalables
Activer les API pour votre projet.
Toute application qui appelle des API Google doit activer ces API dans le API Console.
Pour activer une API pour votre projet:
- Open the API Library dans Google API Console.
- If prompted, select a project, or create a new one.
- Accédez à la page "Bibliothèque" pour trouver et activer l'API YouTube Data. Recherchez les autres API que votre application utilisera et activez-les également.
Créer des identifiants d'autorisation
Toute application qui utilise OAuth 2.0 pour accéder aux API Google doit disposer d'identifiants d'autorisation qui identifient l'application auprès du serveur OAuth 2.0 de Google. Les étapes suivantes expliquent comment créer des identifiants pour votre projet. Vos applications peuvent ensuite utiliser ces identifiants pour accéder aux API que vous avez activées pour ce projet.
- Go to the Credentials page.
- Cliquez sur Créer des identifiants > ID client OAuth.
- Sélectionnez le type d'application Application Web.
- Remplissez le formulaire, puis cliquez sur Créer. Les applications qui utilisent des langages et des frameworks tels que PHP, Java, Python, Ruby et .NET doivent spécifier des URI de redirection autorisés. Les URI de redirection sont les points de terminaison auxquels le serveur OAuth 2.0 peut envoyer des réponses. Ces points de terminaison doivent respecter les règles de validation de Google.
Pour les tests, vous pouvez spécifier des URI qui font référence à la machine locale, tels que
http://localhost:8080
. Gardez cela à l'esprit que tous les exemples de ce document utilisenthttp://localhost:8080
comme URI de redirection.Nous vous recommandons de concevoir les points de terminaison d'authentification de votre application afin que celle-ci n'expose pas les codes d'autorisation à d'autres ressources de la page.
Après avoir créé vos identifiants, téléchargez le fichier client_secret.json à partir de API Console. Stockez le fichier de manière sécurisée dans un emplacement auquel seule votre application peut accéder.
Identifier les niveaux d'accès
Les niveaux d'accès permettent à votre application de ne demander l'accès qu'aux ressources dont elle a besoin, tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils accordent à votre application. Ainsi, il peut y avoir une relation inverse entre le nombre de champs d'application demandés et la probabilité d'obtenir le consentement de l'utilisateur.
Avant de commencer à implémenter l'autorisation OAuth 2.0, nous vous recommandons d'identifier les champs d'application pour lesquels votre application aura besoin d'une autorisation d'accès.
Nous recommandons également que votre application demande l'accès aux champs d'application d'autorisation via un processus d'autorisation incrémentielle, dans lequel votre application demande l'accès aux données utilisateur en contexte. Cette bonne pratique aide les utilisateurs à comprendre plus facilement pourquoi votre application a besoin de l'accès demandé.
La version 3 de l'API YouTube Data utilise les champs d'application suivants:
Niveaux d'accès | |
---|---|
https://www.googleapis.com/auth/youtube | Gérez votre compte YouTube. |
https://www.googleapis.com/auth/youtube.channel-memberships.creator | Consulter la liste des membres actuellement actifs de votre chaîne, leur niveau actuel et leur date de souscription |
https://www.googleapis.com/auth/youtube.force-ssl | Afficher, modifier et supprimer définitivement vos vidéos, notes, commentaires et sous-titres YouTube |
https://www.googleapis.com/auth/youtube.readonly | Consultez votre compte YouTube. |
https://www.googleapis.com/auth/youtube.upload | Gérez vos vidéos YouTube. |
https://www.googleapis.com/auth/youtubepartner | Affichez et gérez vos éléments et le contenu associé sur YouTube. |
https://www.googleapis.com/auth/youtubepartner-channel-audit | Affichez les informations privées sur votre chaîne YouTube pertinentes pendant le processus d'audit avec un partenaire YouTube. |
Le document Champs d'application de l'API OAuth 2.0 contient la liste complète des champs d'application que vous pouvez utiliser pour accéder aux API Google.
Exigences propres à la langue
Pour exécuter l'un des exemples de code présentés dans ce document, vous devez disposer d'un compte Google, d'un accès à Internet et d'un navigateur Web. Si vous utilisez l'une des bibliothèques clientes de l'API, consultez également les exigences spécifiques aux langages ci-dessous.
PHP
Pour exécuter les exemples de code PHP de ce document, vous avez besoin des éléments suivants:
- PHP 5.6 ou version ultérieure, avec l'interface de ligne de commande (CLI) et l'extension JSON installées
- L'outil de gestion des dépendances Composer
-
Bibliothèque cliente des API Google pour PHP:
composer require google/apiclient:^2.10
Python
Pour exécuter les exemples de code Python présentés dans ce document, vous avez besoin des éléments suivants:
- Python 2.6 ou version ultérieure
- L'outil de gestion de packages pip
- Bibliothèque cliente des API Google pour Python :
pip install --upgrade google-api-python-client
- Les éléments
google-auth
,google-auth-oauthlib
etgoogle-auth-httplib2
pour l'autorisation de l'utilisateur.pip install --upgrade google-auth google-auth-oauthlib google-auth-httplib2
- Framework d'applications Web Python Flask.
pip install --upgrade flask
- Bibliothèque HTTP
requests
.pip install --upgrade requests
Ruby
Pour exécuter les exemples de code Ruby présentés dans ce document, vous avez besoin des éléments suivants:
- Ruby 2.6 ou version ultérieure
-
La bibliothèque Google Auth pour Ruby:
gem install googleauth
-
Framework d'applications Web Sinatra Ruby.
gem install sinatra
Node.js
Pour exécuter les exemples de code Node.js présentés dans ce document, vous avez besoin des éléments suivants:
- La version LTS de maintenance, la version LTS active ou la version actuelle de Node.js.
-
Le client Node.js des API Google:
npm install googleapis crypto express express-session
HTTP/REST
Vous n'avez pas besoin d'installer de bibliothèques pour pouvoir appeler directement les points de terminaison OAuth 2.0.
Obtenir des jetons d'accès OAuth 2.0
Les étapes suivantes montrent comment votre application interagit avec le serveur OAuth 2.0 de Google afin d'obtenir l'autorisation d'un utilisateur pour effectuer une requête API en son nom. Votre application doit disposer de ce consentement pour pouvoir exécuter une requête API Google nécessitant l'autorisation de l'utilisateur.
La liste ci-dessous résume brièvement ces étapes:
- Votre application identifie les autorisations dont elle a besoin.
- Votre application redirige l'utilisateur vers Google avec la liste des autorisations demandées.
- L'utilisateur décide d'accorder ou non les autorisations à votre application.
- Votre application détermine ce que l'utilisateur a décidé.
- Si l'utilisateur a accordé les autorisations demandées, votre application récupère les jetons nécessaires pour effectuer des requêtes API au nom de l'utilisateur.
Étape 1: Définissez les paramètres d'autorisation
La première étape consiste à créer la demande d'autorisation. Cette requête définit des paramètres qui identifient votre application ainsi que les autorisations que l'utilisateur sera invité à accorder à votre application.
- Si vous utilisez une bibliothèque cliente Google pour l'authentification et l'autorisation OAuth 2.0, vous créez et configurez un objet qui définit ces paramètres.
- Si vous appelez directement le point de terminaison Google OAuth 2.0, vous générez une URL et définissez les paramètres sur cette URL.
Les onglets ci-dessous définissent les paramètres d'autorisation pris en charge pour les applications de serveur Web. Les exemples propres à un langage montrent également comment utiliser une bibliothèque cliente ou une bibliothèque d'autorisation pour configurer un objet qui définit ces paramètres.
PHP
L'extrait de code ci-dessous crée un objet Google\Client()
, qui définit les paramètres de la requête d'autorisation.
Cet objet identifie votre application à l'aide des informations de votre fichier client_secret.json. Pour en savoir plus sur ce fichier, consultez la section Créer des identifiants d'autorisation. L'objet identifie également les champs d'application pour lesquels votre application demande l'autorisation d'accéder et l'URL du point de terminaison d'authentification de votre application, qui gérera la réponse du serveur OAuth 2.0 de Google. Enfin, le code définit les paramètres facultatifs access_type
et include_granted_scopes
.
Par exemple, pour demander un accès hors connexion afin de récupérer les données YouTube d'un utilisateur:
$client = new Google\Client(); // Required, call the setAuthConfig function to load authorization credentials from // client_secret.json file. $client->setAuthConfig('client_secret.json'); // Required, to set the scope value, call the addScope function $client->addScope(Google_Service_YouTube::YOUTUBE_FORCE_SSL); // Required, call the setRedirectUri function to specify a valid redirect URI for the // provided client_id $client->setRedirectUri('http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php'); // Recommended, offline access will give you both an access and refresh token so that // your app can refresh the access token without user interaction. $client->setAccessType('offline'); // Recommended, call the setState function. Using a state value can increase your assurance that // an incoming connection is the result of an authentication request. $client->setState($sample_passthrough_value); // Optional, if your application knows which user is trying to authenticate, it can use this // parameter to provide a hint to the Google Authentication Server. $client->setLoginHint('hint@example.com'); // Optional, call the setPrompt function to set "consent" will prompt the user for consent $client->setPrompt('consent'); // Optional, call the setIncludeGrantedScopes function with true to enable incremental // authorization $client->setIncludeGrantedScopes(true);
Python
L'extrait de code suivant utilise le module google-auth-oauthlib.flow
pour construire la requête d'autorisation.
Le code construit un objet Flow
, qui identifie votre application à l'aide des informations du fichier client_secret.json que vous avez téléchargé après avoir créé des identifiants d'autorisation. Cet objet identifie également les champs d'application pour lesquels votre application demande l'autorisation d'accéder et l'URL du point de terminaison d'authentification de votre application, qui gérera la réponse du serveur OAuth 2.0 de Google. Enfin, le code définit les paramètres facultatifs access_type
et include_granted_scopes
.
Par exemple, pour demander un accès hors connexion afin de récupérer les données YouTube d'un utilisateur:
import google.oauth2.credentials import google_auth_oauthlib.flow # Required, call the from_client_secrets_file method to retrieve the client ID from a # client_secret.json file. The client ID (from that file) and access scopes are required. (You can # also use the from_client_config method, which passes the client configuration as it originally # appeared in a client secrets file but doesn't access the file itself.) flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file( 'client_secret.json', scopes=['https://www.googleapis.com/auth/youtube.force-ssl']) # Required, indicate where the API server will redirect the user after the user completes # the authorization flow. The redirect URI is required. The value must exactly # match one of the authorized redirect URIs for the OAuth 2.0 client, which you # configured in the API Console. If this value doesn't match an authorized URI, # you will get a 'redirect_uri_mismatch' error. flow.redirect_uri = 'https://www.example.com/oauth2callback' # Generate URL for request to Google's OAuth 2.0 server. # Use kwargs to set optional request parameters. authorization_url, state = flow.authorization_url( # Recommended, enable offline access so that you can refresh an access token without # re-prompting the user for permission. Recommended for web server apps. access_type='offline', # Optional, enable incremental authorization. Recommended as a best practice. include_granted_scopes='true', # Optional, if your application knows which user is trying to authenticate, it can use this # parameter to provide a hint to the Google Authentication Server. login_hint='hint@example.com', # Optional, set prompt to 'consent' will prompt the user for consent prompt='consent')
Ruby
Utilisez le fichier client_secrets.json que vous avez créé pour configurer un objet client dans votre application. Lorsque vous configurez un objet client, vous spécifiez les niveaux d'accès auxquels votre application doit accéder, ainsi que l'URL du point de terminaison d'authentification de votre application, qui gérera la réponse du serveur OAuth 2.0.
Par exemple, pour demander un accès hors connexion afin de récupérer les données YouTube d'un utilisateur:
require 'google/apis/youtube_v3' require "googleauth" require 'googleauth/stores/redis_token_store' client_id = Google::Auth::ClientId.from_file('/path/to/client_secret.json') scope = 'https://www.googleapis.com/auth/youtube.force-ssl' token_store = Google::Auth::Stores::RedisTokenStore.new(redis: Redis.new) authorizer = Google::Auth::WebUserAuthorizer.new(client_id, scope, token_store, '/oauth2callback')
Votre application utilise l'objet client pour effectuer des opérations OAuth 2.0, telles que la génération d'URL de demande d'autorisation et l'application de jetons d'accès aux requêtes HTTP.
Node.js
L'extrait de code suivant crée un objet google.auth.OAuth2
, qui définit les paramètres de la requête d'autorisation.
Cet objet identifie votre application à l'aide des informations de votre fichier client_secret.json. Pour demander à un utilisateur l'autorisation de récupérer un jeton d'accès, vous devez le rediriger vers une page de consentement. Pour créer une URL de page de consentement:
const {google} = require('googleapis'); const crypto = require('crypto'); const express = require('express'); const session = require('express-session'); /** * To use OAuth2 authentication, we need access to a CLIENT_ID, CLIENT_SECRET, AND REDIRECT_URI * from the client_secret.json file. To get these credentials for your application, visit * https://console.cloud.google.com/apis/credentials. */ const oauth2Client = new google.auth.OAuth2( YOUR_CLIENT_ID, YOUR_CLIENT_SECRET, YOUR_REDIRECT_URL ); // Access scopes for read-only Drive activity. const scopes = [ 'https://www.googleapis.com/auth/drive.metadata.readonly' ]; // Generate a secure random state value. const state = crypto.randomBytes(32).toString('hex'); // Store state in the session req.session.state = state; // Generate a url that asks permissions for the Drive activity scope const authorizationUrl = oauth2Client.generateAuthUrl({ // 'online' (default) or 'offline' (gets refresh_token) access_type: 'offline', /** Pass in the scopes array defined above. * Alternatively, if only one scope is needed, you can pass a scope URL as a string */ scope: scopes, // Enable incremental authorization. Recommended as a best practice. include_granted_scopes: true, // Include the state parameter to reduce the risk of CSRF attacks. state: state });
Remarque importante : refresh_token
n'est renvoyé que lors de la première autorisation.
En savoir plus
HTTP/REST
Le point de terminaison OAuth 2.0 de Google est à https://accounts.google.com/o/oauth2/v2/auth
. Ce point de terminaison n'est accessible que via HTTPS. Les connexions HTTP ordinaires sont refusées.
Le serveur d'autorisation Google accepte les paramètres de chaîne de requête suivants pour les applications de serveur Web:
Paramètres | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
client_id |
Obligatoire
ID client de votre application. Vous trouverez cette valeur dans API Console Credentials page. |
||||||||||||||||
redirect_uri |
Obligatoire
Détermine où le serveur d'API redirige l'utilisateur une fois que celui-ci a terminé le flux d'autorisation. La valeur doit correspondre exactement à l'un des URI de redirection autorisés pour le client OAuth 2.0, que vous avez configurés dans le fichier Credentials page API Consolede votre client. Si cette valeur ne correspond pas à un URI de redirection autorisé pour l'élément Notez que le schéma |
||||||||||||||||
response_type |
Obligatoire
Détermine si le point de terminaison Google OAuth 2.0 renvoie un code d'autorisation. Définissez la valeur du paramètre sur |
||||||||||||||||
scope |
Obligatoire
Liste de champs d'application délimités par des espaces qui identifient les ressources auxquelles votre application peut accéder pour le compte de l'utilisateur. Ces valeurs déterminent l'écran de consentement que Google présente à l'utilisateur. Les niveaux d'accès permettent à votre application de ne demander l'accès qu'aux ressources dont elle a besoin, tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils accordent à votre application. Ainsi, il existe une relation inverse entre le nombre de champs d'application demandés et la probabilité d'obtenir le consentement de l'utilisateur. La version 3 de l'API YouTube Data utilise les champs d'application suivants:
Le document Champs d'application des API OAuth 2.0 fournit une liste complète des champs d'application que vous pouvez utiliser pour accéder aux API Google. Dans la mesure du possible, nous vous recommandons de demander à votre application l'accès aux champs d'application d'autorisation en contexte. En demandant l'accès aux données utilisateur en contexte via une autorisation incrémentielle, vous aidez les utilisateurs à comprendre plus facilement pourquoi votre application a besoin de l'accès demandé. |
||||||||||||||||
access_type |
Recommandé
Indique si votre application peut actualiser les jetons d'accès lorsque l'utilisateur n'est pas présent dans le navigateur. Les valeurs de paramètres valides sont Définissez la valeur sur |
||||||||||||||||
state |
Recommandé
Spécifie toute valeur de chaîne que votre application utilise pour maintenir l'état entre votre demande d'autorisation et la réponse du serveur d'autorisation.
Le serveur renvoie la valeur exacte que vous envoyez en tant que paire Vous pouvez utiliser ce paramètre à différentes fins, par exemple pour rediriger l'utilisateur vers la ressource appropriée dans votre application, envoyer des nonces ou limiter la falsification des requêtes intersites. Étant donné que votre |
||||||||||||||||
include_granted_scopes |
Optional
Permet aux applications d'utiliser une autorisation incrémentielle pour demander l'accès à des champs d'application supplémentaires en contexte. Si vous définissez la valeur de ce paramètre sur |
||||||||||||||||
enable_granular_consent |
Optional
La valeur par défaut est Lorsque Google active des autorisations précises pour une application, ce paramètre n'a plus aucun effet. |
||||||||||||||||
login_hint |
Optional
Si votre application sait quel utilisateur tente de s'authentifier, elle peut utiliser ce paramètre pour fournir un indice au serveur d'authentification Google. Le serveur utilise cet indice pour simplifier le processus de connexion, soit en préremplissant le champ d'adresse e-mail dans le formulaire de connexion, soit en sélectionnant la session multiconnexion appropriée. Définissez la valeur du paramètre sur une adresse e-mail ou un identifiant |
||||||||||||||||
prompt |
Optional
Liste de requêtes sensibles à la casse et séparées par des espaces à présenter à l'utilisateur. Si vous ne spécifiez pas ce paramètre, l'utilisateur n'est invité à le faire que la première fois que votre projet demande l'accès. Pour en savoir plus, consultez la section Demander un nouveau consentement. Les valeurs possibles sont :
|
Étape 2: Redirection vers le serveur OAuth 2.0 de Google
Redirigez l'utilisateur vers le serveur OAuth 2.0 de Google pour lancer le processus d'authentification et d'autorisation. En général, cela se produit lorsque votre application doit accéder pour la première fois aux données de l'utilisateur. Dans le cas d'une autorisation incrémentielle, cette étape se produit également lorsque votre application doit accéder pour la première fois à des ressources supplémentaires auxquelles elle n'est pas encore autorisée à accéder.
PHP
- Générez une URL pour demander l'accès au serveur OAuth 2.0 de Google :
$auth_url = $client->createAuthUrl();
- Rediriger l'utilisateur vers
$auth_url
:header('Location: ' . filter_var($auth_url, FILTER_SANITIZE_URL));
Python
Cet exemple montre comment rediriger l'utilisateur vers l'URL d'autorisation à l'aide du framework d'application Web Flask:
return flask.redirect(authorization_url)
Ruby
- Générez une URL pour demander l'accès au serveur OAuth 2.0 de Google :
auth_uri = authorizer.get_authorization_url(login_hint: user_id, request: request)
- Redirigez l'utilisateur vers
auth_uri
.
Node.js
-
Utilisez l'URL
authorizationUrl
générée à l'étape 1generateAuthUrl
pour demander l'accès au serveur OAuth 2.0 de Google. -
Redirigez l'utilisateur vers
authorizationUrl
.res.redirect(authorizationUrl);
HTTP/REST
Sample redirect to Google's authorization server
An example URL is shown below, with line breaks and spaces for readability. The URL requests
access to a scope that permits access to retrieve the user's YouTube data. It uses incremental
authorization (include_granted_scopes=true
) to ensure that the new access token
covers any scopes to which the user previously granted the application access. Several other
parameters are also set in the example.
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl& access_type=offline& include_granted_scopes=true& response_type=code& state=state_parameter_passthrough_value& redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback& client_id=client_id
Une fois l'URL de requête créée, redirigez l'utilisateur vers celle-ci.
Le serveur OAuth 2.0 de Google authentifie l'utilisateur et obtient son consentement pour que votre application puisse accéder aux champs d'application demandés. La réponse est renvoyée à votre application à l'aide de l'URL de redirection que vous avez spécifiée.
Étape 3: Google invite l'utilisateur à donner son consentement
Au cours de cette étape, l'utilisateur décide d'accorder ou non l'accès demandé à votre application. À ce stade, Google affiche une fenêtre de consentement indiquant le nom de votre application et les services d'API Google auxquels il demande l'autorisation d'accéder à l'aide des identifiants de l'utilisateur, ainsi qu'un résumé des champs d'application d'accès à accorder. L'utilisateur peut ensuite accepter d'accorder l'accès à un ou plusieurs champs d'application demandés par votre application, ou refuser la requête.
Votre application n'a rien à faire à ce stade, car elle attend la réponse du serveur OAuth 2.0 de Google indiquant si un accès a été accordé. Cette réponse est expliquée à l'étape suivante.
Erreurs
Les requêtes envoyées au point de terminaison d'autorisation OAuth 2.0 de Google peuvent afficher des messages d'erreur destinés aux utilisateurs au lieu des flux d'authentification et d'autorisation attendus. Les codes d'erreur courants et les solutions suggérées sont répertoriés ci-dessous.
admin_policy_enforced
Le compte Google ne peut pas autoriser un ou plusieurs champs d'application demandés en raison des règles de son administrateur Google Workspace. Consultez l'article d'aide pour les administrateurs Google Workspace Contrôler quelles applications tierces et internes ont accès aux données Google Workspace pour découvrir comment un administrateur peut limiter l'accès à tous les champs d'application ou aux niveaux d'accès sensibles et restreints jusqu'à ce que l'accès soit explicitement accordé à votre ID client OAuth.
disallowed_useragent
Le point de terminaison de l'autorisation s'affiche dans un user-agent intégré non autorisé par les règles OAuth 2.0 de Google.
Android
Les développeurs Android peuvent rencontrer ce message d'erreur lorsqu'ils ouvrent des requêtes d'autorisation dans android.webkit.WebView
.
Les développeurs doivent plutôt utiliser des bibliothèques Android telles que Google Sign-In pour Android ou AppAuth pour Android d'OpenID Foundation.
Les développeurs Web peuvent rencontrer cette erreur lorsqu'une application Android ouvre un lien Web général dans un user-agent intégré et qu'un utilisateur accède au point de terminaison d'autorisation OAuth 2.0 de Google à partir de votre site. Les développeurs doivent autoriser l'ouverture des liens généraux dans le gestionnaire de liens par défaut du système d'exploitation, qui inclut à la fois les gestionnaires Android App Links ou l'application de navigateur par défaut. La bibliothèque Android Custom Tabs est également disponible.
iOS
Les développeurs iOS et macOS peuvent rencontrer cette erreur lors de l'ouverture de demandes d'autorisation dans WKWebView
.
À la place, les développeurs doivent utiliser des bibliothèques iOS telles que Google Sign-In pour iOS ou AppAuth pour iOS d'OpenID Foundation.
Les développeurs Web peuvent rencontrer cette erreur lorsqu'une application iOS ou macOS ouvre un lien Web général dans un user-agent intégré et qu'un utilisateur accède au point de terminaison d'autorisation OAuth 2.0 de Google à partir de votre site. Les développeurs doivent autoriser l'ouverture des liens généraux dans le gestionnaire de liens par défaut du système d'exploitation, qui inclut à la fois les gestionnaires de liens universels ou l'application de navigateur par défaut. La bibliothèque SFSafariViewController
est également une option compatible.
org_internal
L'ID client OAuth de la requête fait partie d'un projet limitant l'accès aux comptes Google dans une organisation Google Cloud spécifique. Pour en savoir plus sur cette option de configuration, consultez la section Type d'utilisateur de l'article d'aide "Configurer l'écran de consentement OAuth".
invalid_client
Le code secret du client OAuth est incorrect. Examinez la configuration du client OAuth, y compris l'ID client et le code secret utilisés pour cette requête.
invalid_grant
Lors de l'actualisation d'un jeton d'accès ou de l'utilisation d'une autorisation incrémentielle, le jeton a peut-être expiré ou a été invalidé. Authentifiez à nouveau l'utilisateur et demandez son consentement pour obtenir de nouveaux jetons. Si l'erreur persiste, vérifiez que votre application a été correctement configurée, et que vous utilisez les jetons et les paramètres appropriés dans votre requête. Sinon, le compte utilisateur a peut-être été supprimé ou désactivé.
redirect_uri_mismatch
L'élément redirect_uri
transmis dans la demande d'autorisation ne correspond à aucun URI de redirection autorisé pour l'ID client OAuth. Examinez les URI de redirection autorisés dans le fichier Google API Console Credentials page.
Le paramètre redirect_uri
peut faire référence au flux OAuth hors bande (OOB) qui est obsolète et n'est plus pris en charge. Consultez le guide de migration pour mettre à jour votre intégration.
invalid_request
Un problème est survenu avec votre demande. Plusieurs raisons peuvent expliquer ce problème:
- Le format de la requête n'est pas correct.
- Il manquait des paramètres obligatoires dans la requête
- La requête utilise une méthode d'autorisation non compatible avec Google. Vérifiez que votre intégration OAuth utilise une méthode d'intégration recommandée
Étape 4: Gérer la réponse du serveur OAuth 2.0
Le serveur OAuth 2.0 répond à la demande d'accès de votre application en utilisant l'URL spécifiée dans la requête.
Si l'utilisateur approuve la demande d'accès, la réponse contient un code d'autorisation. Si l'utilisateur n'approuve pas la requête, la réponse contient un message d'erreur. Le code d'autorisation ou le message d'erreur renvoyé au serveur Web apparaît dans la chaîne de requête, comme indiqué ci-dessous:
Réponse d'erreur:
https://oauth2.example.com/auth?error=access_denied
Réponse avec code d'autorisation:
https://oauth2.example.com/auth?code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7
Exemple de réponse du serveur OAuth 2.0
Vous pouvez tester ce flux en cliquant sur l'URL d'exemple suivante, qui demande un accès en lecture seule pour afficher les métadonnées des fichiers de votre Google Drive:
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl& access_type=offline& include_granted_scopes=true& response_type=code& state=state_parameter_passthrough_value& redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback& client_id=client_id
Une fois le flux OAuth 2.0 terminé, vous devriez être redirigé vers http://localhost/oauth2callback
, ce qui générera probablement une erreur 404 NOT FOUND
, sauf si votre ordinateur local diffuse un fichier à cette adresse. L'étape suivante fournit plus de détails sur les informations renvoyées dans l'URI lorsque l'utilisateur est redirigé vers votre application.
Étape 5: Échangez le code d'autorisation contre des jetons d'actualisation et d'accès
Une fois que le serveur Web a reçu le code d'autorisation, il peut l'échanger contre un jeton d'accès.
PHP
Pour échanger un code d'autorisation contre un jeton d'accès, utilisez la méthode authenticate
:
$client->authenticate($_GET['code']);
Vous pouvez récupérer le jeton d'accès avec la méthode getAccessToken
:
$access_token = $client->getAccessToken();
Python
Sur votre page de rappel, utilisez la bibliothèque google-auth
pour vérifier la réponse du serveur d'autorisation. Ensuite, utilisez la méthode flow.fetch_token
pour échanger le code d'autorisation de cette réponse contre un jeton d'accès:
state = flask.session['state'] flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file( 'client_secret.json', scopes=['https://www.googleapis.com/auth/youtube.force-ssl'], state=state) flow.redirect_uri = flask.url_for('oauth2callback', _external=True) authorization_response = flask.request.url flow.fetch_token(authorization_response=authorization_response) # Store the credentials in the session. # ACTION ITEM for developers: # Store user's access and refresh tokens in your data store if # incorporating this code into your real app. credentials = flow.credentials flask.session['credentials'] = { 'token': credentials.token, 'refresh_token': credentials.refresh_token, 'token_uri': credentials.token_uri, 'client_id': credentials.client_id, 'client_secret': credentials.client_secret, 'scopes': credentials.scopes}
Ruby
Sur votre page de rappel, utilisez la bibliothèque googleauth
pour vérifier la réponse du serveur d'autorisation. Utilisez la méthode authorizer.handle_auth_callback_deferred
pour enregistrer le code d'autorisation et rediriger l'utilisateur vers l'URL de la demande d'autorisation initiale. Cela diffère l'échange du code en stockant temporairement les résultats dans la session de l'utilisateur.
target_url = Google::Auth::WebUserAuthorizer.handle_auth_callback_deferred(request) redirect target_url
Node.js
Pour échanger un code d'autorisation contre un jeton d'accès, utilisez la méthode getToken
:
const url = require('url'); // Receive the callback from Google's OAuth 2.0 server. app.get('/oauth2callback', async (req, res) => { let q = url.parse(req.url, true).query; if (q.error) { // An error response e.g. error=access_denied console.log('Error:' + q.error); } else if (q.state !== req.session.state) { //check state value console.log('State mismatch. Possible CSRF attack'); res.end('State mismatch. Possible CSRF attack'); } else { // Get access and refresh tokens (if access_type is offline) let { tokens } = await oauth2Client.getToken(q.code); oauth2Client.setCredentials(tokens); });
HTTP/REST
Pour échanger un code d'autorisation contre un jeton d'accès, appelez le point de terminaison https://oauth2.googleapis.com/token
et définissez les paramètres suivants:
Champs | |
---|---|
client_id |
ID client obtenu à partir de API Console Credentials page. |
client_secret |
Code secret du client obtenu à partir de API Console Credentials page. |
code |
Code d'autorisation renvoyé par la requête initiale. |
grant_type |
Comme défini dans la spécification OAuth 2.0, la valeur de ce champ doit être définie sur authorization_code . |
redirect_uri |
L'un des URI de redirection répertoriés pour votre projet dans le Credentials page API Consolepour le client_id donné. |
L'extrait de code suivant présente un exemple de requête:
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
Google répond à cette requête en renvoyant un objet JSON contenant un jeton d'accès de courte durée et un jeton d'actualisation.
Notez que le jeton d'actualisation n'est renvoyé que si votre application a défini le paramètre access_type
sur offline
dans la requête initiale adressée au serveur d'autorisation de Google.
La réponse contient les champs suivants :
Champs | |
---|---|
access_token |
Jeton envoyé par votre application pour autoriser une requête API Google. |
expires_in |
Durée de vie restante du jeton d'accès, en secondes. |
refresh_token |
Jeton que vous pouvez utiliser pour obtenir un nouveau jeton d'accès. Les jetons d'actualisation sont valides jusqu'à ce que l'utilisateur révoque l'accès.
Là encore, ce champ n'est présent dans cette réponse que si vous définissez le paramètre access_type sur offline dans la requête initiale adressée au serveur d'autorisation de Google.
|
scope |
Champs d'application d'accès accordés par access_token , exprimés sous la forme d'une liste de chaînes sensibles à la casse et séparées par des espaces. |
token_type |
Type de jeton renvoyé. Pour le moment, la valeur de ce champ est toujours définie sur Bearer . |
L'extrait de code suivant montre un exemple de réponse:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/youtube.force-ssl", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
Erreurs
Lorsque vous échangez le code d'autorisation contre un jeton d'accès, vous pouvez rencontrer l'erreur suivante au lieu de la réponse attendue. Les codes d'erreur courants et les solutions suggérées sont listés ci-dessous.
invalid_grant
Le code d'autorisation fourni n'est pas valide ou n'est pas au bon format. Demandez un nouveau code en redémarrant le processus OAuth afin d'inviter à nouveau l'utilisateur à donner son consentement.
Appeler des API Google
PHP
Utilisez le jeton d'accès pour appeler les API Google en procédant comme suit:
- Si vous devez appliquer un jeton d'accès à un nouvel objet
Google\Client
(par exemple, si vous avez stocké le jeton d'accès dans une session utilisateur), utilisez la méthodesetAccessToken
:$client->setAccessToken($access_token);
- Créez un objet de service pour l'API que vous souhaitez appeler. Pour créer un objet de service, vous devez fournir un objet
Google\Client
autorisé au constructeur de l'API que vous souhaitez appeler. Par exemple, pour appeler l'API YouTube Data :$youtube = new Google_Service_YouTube($client);
- Envoyez des requêtes au service d'API à l'aide de l'interface fournie par l'objet de service.
Par exemple, pour utiliser l'API YouTube Data afin de récupérer la liste des diffusions en direct de la chaîne de l'utilisateur authentifié :
$broadcasts = $youtube->liveBroadcasts->listLiveBroadcasts('id,snippet', [ 'mine' => true ]);
Python
Après avoir obtenu un jeton d'accès, votre application peut l'utiliser pour autoriser les requêtes API au nom d'un compte utilisateur ou d'un compte de service donné. Utilisez les identifiants d'autorisation spécifiques à l'utilisateur pour créer un objet de service pour l'API que vous souhaitez appeler, puis utilisez cet objet pour effectuer des requêtes API autorisées.
- Créez un objet de service pour l'API que vous souhaitez appeler. Pour créer un objet de service, appelez la méthode
build
de la bibliothèquegoogleapiclient.discovery
avec le nom et la version de l'API, ainsi que les identifiants de l'utilisateur : Par exemple, pour appeler la version 3 de l'API YouTube Data :from googleapiclient.discovery import build youtube = build('youtube', 'v3', credentials=credentials)
- Envoyez des requêtes au service d'API à l'aide de l'interface fournie par l'objet de service.
Par exemple, pour utiliser l'API YouTube Data afin de récupérer la liste des diffusions en direct de la chaîne de l'utilisateur authentifié :
broadcasts = youtube.liveBroadcasts().list(part='id,snippet', mine=True).execute()
Ruby
Après avoir obtenu un jeton d'accès, votre application peut l'utiliser pour effectuer des requêtes API au nom d'un compte utilisateur ou d'un compte de service donné. Utilisez les identifiants d'autorisation spécifiques à l'utilisateur pour créer un objet de service pour l'API que vous souhaitez appeler, puis utilisez cet objet pour effectuer des requêtes API autorisées.
- Créez un objet de service pour l'API que vous souhaitez appeler.
Par exemple, pour appeler la version 3 de l'API YouTube Data :
youtube = Google::Apis::YoutubeV3::YouTubeService.new
- Définissez les identifiants sur le service :
youtube.authorization = credentials
- Envoyez des requêtes au service d'API à l'aide de l'interface fournie par l'objet de service.
Par exemple, pour utiliser l'API YouTube Data afin de récupérer la liste des diffusions en direct de la chaîne de l'utilisateur authentifié :
broadcasts = youtube.list_liveBroadcasts('id,snippet', mine: true)
Vous pouvez également accorder l'autorisation pour chaque méthode en fournissant le paramètre options
à une méthode:
broadcasts = youtube.list_liveBroadcasts('id,snippet', mine: true)
Node.js
Après avoir obtenu un jeton d'accès et l'avoir défini sur l'objet OAuth2
, utilisez l'objet pour appeler les API Google. Votre application peut utiliser ce jeton pour autoriser les requêtes API au nom d'un compte utilisateur ou d'un compte de service donné. Créez un objet de service pour l'API que vous souhaitez appeler.
const { google } = require('googleapis'); // Example of using Google Drive API to list filenames in user's Drive. const drive = google.drive('v3'); drive.files.list({ auth: oauth2Client, pageSize: 10, fields: 'nextPageToken, files(id, name)', }, (err1, res1) => { if (err1) return console.log('The API returned an error: ' + err1); const files = res1.data.files; if (files.length) { console.log('Files:'); files.map((file) => { console.log(`${file.name} (${file.id})`); }); } else { console.log('No files found.'); } });
HTTP/REST
Une fois que votre application a obtenu un jeton d'accès, vous pouvez l'utiliser pour appeler une API Google au nom d'un compte utilisateur donné si les champs d'application d'accès requis par l'API ont été accordés. Pour ce faire, incluez le jeton d'accès dans une requête adressée à l'API en incluant un paramètre de requête access_token
ou une valeur d'en-tête HTTP Authorization
Bearer
. Dans la mesure du possible, l'en-tête HTTP est préférable, car les chaînes de requête ont tendance à être visibles dans les journaux du serveur. Dans la plupart des cas, vous pouvez utiliser une bibliothèque cliente pour configurer vos appels aux API Google (par exemple, lorsque vous appelez l'API YouTube Live Streaming).
Notez que l'API YouTube Live Streaming n'est pas compatible avec le flux du compte de service. Étant donné qu'il n'existe aucun moyen d'associer un compte de service à un compte YouTube, toute tentative d'autorisation des requêtes avec ce flux générera une erreur NoLinkedYouTubeAccount
.
Vous pouvez essayer toutes les API Google et consulter leurs champs d'application sur le site OAuth 2.0 Playground.
Exemples de requête HTTP GET
Un appel au point de terminaison
liveBroadcasts.list
(API YouTube Live Streaming) à l'aide de l'en-tête HTTP Authorization: Bearer
peut se présenter comme suit. Notez que vous devez spécifier votre propre jeton d'accès:
GET /youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
Voici un appel à la même API pour l'utilisateur authentifié à l'aide du paramètre de chaîne de requête access_token
:
GET https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true
curl
exemples
Vous pouvez tester ces commandes avec l'application de ligne de commande curl
. Voici un exemple qui utilise l'option d'en-tête HTTP (recommandée):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true
Vous pouvez également utiliser l'option de paramètre de chaîne de requête:
curl https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true
Exemple complet
L'exemple suivant affiche un objet au format JSON affichant des diffusions en direct pour la chaîne YouTube de l'utilisateur authentifié une fois que celui-ci a autorisé l'application à récupérer ces données.
PHP
Pour exécuter cet exemple:
- Dans le fichier API Console, ajoutez l'URL de la machine locale à la liste des URL de redirection. Par exemple, ajoutez
http://localhost:8080
. - Créez un répertoire et accédez-y. Exemple :
mkdir ~/php-oauth2-example cd ~/php-oauth2-example
- Installez la bibliothèque cliente des API Google pour PHP à l'aide de Composer :
composer require google/apiclient:^2.10
- Créez les fichiers
index.php
etoauth2callback.php
avec le contenu ci-dessous. - Exécutez l'exemple avec un serveur Web configuré pour diffuser PHP. Si vous utilisez PHP 5.6 ou une version ultérieure, vous pouvez utiliser le serveur Web de test intégré de PHP :
php -S localhost:8080 ~/php-oauth2-example
index.php
<?php require_once __DIR__.'/vendor/autoload.php'; session_start(); $client = new Google\Client(); $client->setAuthConfig('client_secrets.json'); $client->addScope(Google_Service_YouTube::YOUTUBE_FORCE_SSL); if (isset($_SESSION['access_token']) && $_SESSION['access_token']) { $client->setAccessToken($_SESSION['access_token']); $youtube = new Google_Service_YouTube($client); $broadcasts = $youtube->liveBroadcasts->listLiveBroadcasts('id,snippet', [ 'mine' => true ]); echo json_encode($broadcasts); } else { $redirect_uri = 'http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php'; header('Location: ' . filter_var($redirect_uri, FILTER_SANITIZE_URL)); }
oauth2callback.php
<?php require_once __DIR__.'/vendor/autoload.php'; session_start(); $client = new Google\Client(); $client->setAuthConfigFile('client_secrets.json'); $client->setRedirectUri('http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php'); $client->addScope(Google_Service_YouTube::YOUTUBE_FORCE_SSL); if (! isset($_GET['code'])) { // Generate and set state value $state = bin2hex(random_bytes(16)); $client->setState($state); $_SESSION['state'] = $state; $auth_url = $client->createAuthUrl(); header('Location: ' . filter_var($auth_url, FILTER_SANITIZE_URL)); } else { // Check the state value if (!isset($_GET['state']) || $_GET['state'] !== $_SESSION['state']) { die('State mismatch. Possible CSRF attack.'); } $client->authenticate($_GET['code']); $_SESSION['access_token'] = $client->getAccessToken(); $redirect_uri = 'http://' . $_SERVER['HTTP_HOST'] . '/'; header('Location: ' . filter_var($redirect_uri, FILTER_SANITIZE_URL)); }
Python
Cet exemple utilise le framework Flask. Il exécute une application Web à l'adresse http://localhost:8080
qui vous permet de tester le flux OAuth 2.0. Si vous accédez à cette URL, vous devriez voir quatre liens:
- Tester une requête API:ce lien redirige vers une page qui tente d'exécuter un exemple de requête API. Si nécessaire, il lance le flux d'autorisation. Si l'opération réussit, la page affiche la réponse de l'API.
- Tester directement le flux d'authentification:ce lien redirige vers une page qui tente de rediriger l'utilisateur vers le flux d'autorisation. L'application demande l'autorisation d'envoyer des requêtes API autorisées au nom de l'utilisateur.
- Révoquer les identifiants actuels:ce lien redirige vers une page qui révoque les autorisations que l'utilisateur a déjà accordées à l'application.
- Effacer les identifiants de session Flask:ce lien efface les identifiants d'autorisation stockés dans la session Flask. Cela vous permet de voir ce qui se passerait si un utilisateur qui avait déjà accordé des autorisations à votre application tentait d'exécuter une requête API dans une nouvelle session. Il vous permet également de voir la réponse de l'API que votre application obtiendrait si un utilisateur avait révoqué les autorisations accordées à votre application, et que votre application aurait quand même tenté d'autoriser une requête avec un jeton d'accès révoqué.
# -*- coding: utf-8 -*- import os import flask import requests import google.oauth2.credentials import google_auth_oauthlib.flow import googleapiclient.discovery # This variable specifies the name of a file that contains the OAuth 2.0 # information for this application, including its client_id and client_secret. CLIENT_SECRETS_FILE = "client_secret.json" # This OAuth 2.0 access scope allows for full read/write access to the # authenticated user's account and requires requests to use an SSL connection. SCOPES = ['https://www.googleapis.com/auth/youtube.force-ssl'] API_SERVICE_NAME = 'youtube' API_VERSION = 'v3' app = flask.Flask(__name__) # Note: A secret key is included in the sample so that it works. # If you use this code in your application, replace this with a truly secret # key. See https://flask.palletsprojects.com/quickstart/#sessions. app.secret_key = 'REPLACE ME - this value is here as a placeholder.' @app.route('/') def index(): return print_index_table() @app.route('/test') def test_api_request(): if 'credentials' not in flask.session: return flask.redirect('authorize') # Load credentials from the session. credentials = google.oauth2.credentials.Credentials( **flask.session['credentials']) youtube = googleapiclient.discovery.build( API_SERVICE_NAME, API_VERSION, credentials=credentials) broadcasts = youtube.liveBroadcasts().list(part='id,snippet', mine=True).execute() # Save credentials back to session in case access token was refreshed. # ACTION ITEM: In a production app, you likely want to save these # credentials in a persistent database instead. flask.session['credentials'] = credentials_to_dict(credentials) return flask.jsonify(**broadcasts) @app.route('/authorize') def authorize(): # Create flow instance to manage the OAuth 2.0 Authorization Grant Flow steps. flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file( CLIENT_SECRETS_FILE, scopes=SCOPES) # The URI created here must exactly match one of the authorized redirect URIs # for the OAuth 2.0 client, which you configured in the API Console. If this # value doesn't match an authorized URI, you will get a 'redirect_uri_mismatch' # error. flow.redirect_uri = flask.url_for('oauth2callback', _external=True) authorization_url, state = flow.authorization_url( # Enable offline access so that you can refresh an access token without # re-prompting the user for permission. Recommended for web server apps. access_type='offline', # Enable incremental authorization. Recommended as a best practice. include_granted_scopes='true') # Store the state so the callback can verify the auth server response. flask.session['state'] = state return flask.redirect(authorization_url) @app.route('/oauth2callback') def oauth2callback(): # Specify the state when creating the flow in the callback so that it can # verified in the authorization server response. state = flask.session['state'] flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file( CLIENT_SECRETS_FILE, scopes=SCOPES, state=state) flow.redirect_uri = flask.url_for('oauth2callback', _external=True) # Use the authorization server's response to fetch the OAuth 2.0 tokens. authorization_response = flask.request.url flow.fetch_token(authorization_response=authorization_response) # Store credentials in the session. # ACTION ITEM: In a production app, you likely want to save these # credentials in a persistent database instead. credentials = flow.credentials flask.session['credentials'] = credentials_to_dict(credentials) return flask.redirect(flask.url_for('test_api_request')) @app.route('/revoke') def revoke(): if 'credentials' not in flask.session: return ('You need to <a href="/authorize">authorize</a> before ' + 'testing the code to revoke credentials.') credentials = google.oauth2.credentials.Credentials( **flask.session['credentials']) revoke = requests.post('https://oauth2.googleapis.com/revoke', params={'token': credentials.token}, headers = {'content-type': 'application/x-www-form-urlencoded'}) status_code = getattr(revoke, 'status_code') if status_code == 200: return('Credentials successfully revoked.' + print_index_table()) else: return('An error occurred.' + print_index_table()) @app.route('/clear') def clear_credentials(): if 'credentials' in flask.session: del flask.session['credentials'] return ('Credentials have been cleared.<br><br>' + print_index_table()) def credentials_to_dict(credentials): return {'token': credentials.token, 'refresh_token': credentials.refresh_token, 'token_uri': credentials.token_uri, 'client_id': credentials.client_id, 'client_secret': credentials.client_secret, 'scopes': credentials.scopes} def print_index_table(): return ('<table>' + '<tr><td><a href="/test">Test an API request</a></td>' + '<td>Submit an API request and see a formatted JSON response. ' + ' Go through the authorization flow if there are no stored ' + ' credentials for the user.</td></tr>' + '<tr><td><a href="/authorize">Test the auth flow directly</a></td>' + '<td>Go directly to the authorization flow. If there are stored ' + ' credentials, you still might not be prompted to reauthorize ' + ' the application.</td></tr>' + '<tr><td><a href="/revoke">Revoke current credentials</a></td>' + '<td>Revoke the access token associated with the current user ' + ' session. After revoking credentials, if you go to the test ' + ' page, you should see an <code>invalid_grant</code> error.' + '</td></tr>' + '<tr><td><a href="/clear">Clear Flask session credentials</a></td>' + '<td>Clear the access token currently stored in the user session. ' + ' After clearing the token, if you <a href="/test">test the ' + ' API request</a> again, you should go back to the auth flow.' + '</td></tr></table>') if __name__ == '__main__': # When running locally, disable OAuthlib's HTTPs verification. # ACTION ITEM for developers: # When running in production *do not* leave this option enabled. os.environ['OAUTHLIB_INSECURE_TRANSPORT'] = '1' # Specify a hostname and port that are set as a valid redirect URI # for your API project in the Google API Console. app.run('localhost', 8080, debug=True)
Ruby
Cet exemple utilise le framework Sinatra.
require 'google/apis/youtube_v3' require 'sinatra' require 'googleauth' require 'googleauth/stores/redis_token_store' configure do enable :sessions set :client_id, Google::Auth::ClientId.from_file('/path/to/client_secret.json') set :scope, Google::Apis::DriveV3::AUTH_DRIVE_METADATA_READONLY set :token_store, Google::Auth::Stores::RedisTokenStore.new(redis: Redis.new) set :authorizer, Google::Auth::WebUserAuthorizer.new(settings.client_id, settings.scope, settings.token_store, '/oauth2callback') end get '/' do user_id = settings.client_id.id credentials = settings.authorizer.get_credentials(user_id, request) if credentials.nil? redirect settings.authorizer.get_authorization_url(login_hint: user_id, request: request) end youtube = Google::Apis::YoutubeV3::YouTubeService.new broadcasts = youtube.list_liveBroadcasts('id,snippet', mine: true) "<pre>#{JSON.pretty_generate(broadcasts.to_h)}</pre>" end get '/oauth2callback' do target_url = Google::Auth::WebUserAuthorizer.handle_auth_callback_deferred(request) redirect target_url end
Node.js
Pour exécuter cet exemple:
-
Dans le fichier API Console, ajoutez l'URL de la machine locale à la liste des URL de redirection. Par exemple, ajoutez
http://localhost
. - Assurez-vous que le LTS de maintenance, la version LTS active ou la version actuelle de Node.js sont installés.
-
Créez un répertoire et accédez-y. Exemple :
mkdir ~/nodejs-oauth2-example cd ~/nodejs-oauth2-example
-
Install the
Google API Client
Library
for Node.js using npm:
npm install googleapis
-
Créez les fichiers
main.js
avec le contenu ci-dessous. -
Exécutez l'exemple :
node .\main.js
main.js
const http = require('http'); const https = require('https'); const url = require('url'); const { google } = require('googleapis'); const crypto = require('crypto'); const express = require('express'); const session = require('express-session'); /** * To use OAuth2 authentication, we need access to a CLIENT_ID, CLIENT_SECRET, AND REDIRECT_URI. * To get these credentials for your application, visit * https://console.cloud.google.com/apis/credentials. */ const oauth2Client = new google.auth.OAuth2( YOUR_CLIENT_ID, YOUR_CLIENT_SECRET, YOUR_REDIRECT_URL ); // Access scopes for read-only Drive activity. const scopes = [ 'https://www.googleapis.com/auth/drive.metadata.readonly' ]; /* Global variable that stores user credential in this code example. * ACTION ITEM for developers: * Store user's refresh token in your data store if * incorporating this code into your real app. * For more information on handling refresh tokens, * see https://github.com/googleapis/google-api-nodejs-client#handling-refresh-tokens */ let userCredential = null; async function main() { const app = express(); app.use(session({ secret: 'your_secure_secret_key', // Replace with a strong secret resave: false, saveUninitialized: false, })); // Example on redirecting user to Google's OAuth 2.0 server. app.get('/', async (req, res) => { // Generate a secure random state value. const state = crypto.randomBytes(32).toString('hex'); // Store state in the session req.session.state = state; // Generate a url that asks permissions for the Drive activity scope const authorizationUrl = oauth2Client.generateAuthUrl({ // 'online' (default) or 'offline' (gets refresh_token) access_type: 'offline', /** Pass in the scopes array defined above. * Alternatively, if only one scope is needed, you can pass a scope URL as a string */ scope: scopes, // Enable incremental authorization. Recommended as a best practice. include_granted_scopes: true, // Include the state parameter to reduce the risk of CSRF attacks. state: state }); res.redirect(authorizationUrl); }); // Receive the callback from Google's OAuth 2.0 server. app.get('/oauth2callback', async (req, res) => { // Handle the OAuth 2.0 server response let q = url.parse(req.url, true).query; if (q.error) { // An error response e.g. error=access_denied console.log('Error:' + q.error); } else if (q.state !== req.session.state) { //check state value console.log('State mismatch. Possible CSRF attack'); res.end('State mismatch. Possible CSRF attack'); } else { // Get access and refresh tokens (if access_type is offline) let { tokens } = await oauth2Client.getToken(q.code); oauth2Client.setCredentials(tokens); /** Save credential to the global variable in case access token was refreshed. * ACTION ITEM: In a production app, you likely want to save the refresh token * in a secure persistent database instead. */ userCredential = tokens; // Example of using Google Drive API to list filenames in user's Drive. const drive = google.drive('v3'); drive.files.list({ auth: oauth2Client, pageSize: 10, fields: 'nextPageToken, files(id, name)', }, (err1, res1) => { if (err1) return console.log('The API returned an error: ' + err1); const files = res1.data.files; if (files.length) { console.log('Files:'); files.map((file) => { console.log(`${file.name} (${file.id})`); }); } else { console.log('No files found.'); } }); } }); // Example on revoking a token app.get('/revoke', async (req, res) => { // Build the string for the POST request let postData = "token=" + userCredential.access_token; // Options for POST request to Google's OAuth 2.0 server to revoke a token let postOptions = { host: 'oauth2.googleapis.com', port: '443', path: '/revoke', method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded', 'Content-Length': Buffer.byteLength(postData) } }; // Set up the request const postReq = https.request(postOptions, function (res) { res.setEncoding('utf8'); res.on('data', d => { console.log('Response: ' + d); }); }); postReq.on('error', error => { console.log(error) }); // Post the request with data postReq.write(postData); postReq.end(); }); const server = http.createServer(app); server.listen(80); } main().catch(console.error);
HTTP/REST
Cet exemple Python utilise le framework Flask et la bibliothèque Requests pour illustrer le flux Web OAuth 2.0. Nous vous recommandons d'utiliser la bibliothèque cliente des API Google pour Python pour ce flux. (L'exemple de l'onglet Python utilise la bibliothèque cliente.)
import json import flask import requests app = flask.Flask(__name__) CLIENT_ID = '123456789.apps.googleusercontent.com' CLIENT_SECRET = 'abc123' # Read from a file or environmental variable in a real app SCOPE = 'https://www.googleapis.com/auth/youtube.force-ssl' REDIRECT_URI = 'http://example.com/oauth2callback' @app.route('/') def index(): if 'credentials' not in flask.session: return flask.redirect(flask.url_for('oauth2callback')) credentials = json.loads(flask.session['credentials']) if credentials['expires_in'] <= 0: return flask.redirect(flask.url_for('oauth2callback')) else: headers = {'Authorization': 'Bearer {}'.format(credentials['access_token'])} req_uri = 'https://youtube.googleapis.com/youtube/v3/liveBroadcasts' r = requests.get(req_uri, headers=headers) return r.text @app.route('/oauth2callback') def oauth2callback(): if 'code' not in flask.request.args: state = str(uuid.uuid4()) flask.session['state'] = state auth_uri = ('https://accounts.google.com/o/oauth2/v2/auth?response_type=code' '&client_id={}&redirect_uri={}&scope={}&state={}').format(CLIENT_ID, REDIRECT_URI, SCOPE, state) return flask.redirect(auth_uri) else: if 'state' not in flask.request.args or flask.request.args['state'] != flask.session['state']: return 'State mismatch. Possible CSRF attack.', 400 auth_code = flask.request.args.get('code') data = {'code': auth_code, 'client_id': CLIENT_ID, 'client_secret': CLIENT_SECRET, 'redirect_uri': REDIRECT_URI, 'grant_type': 'authorization_code'} r = requests.post('https://oauth2.googleapis.com/token', data=data) flask.session['credentials'] = r.text return flask.redirect(flask.url_for('index')) if __name__ == '__main__': import uuid app.secret_key = str(uuid.uuid4()) app.debug = False app.run()
Règles de validation de l'URI de redirection
Google applique les règles de validation suivantes pour rediriger les URI afin d'aider les développeurs à sécuriser leurs applications. Vos URI de redirection doivent respecter ces règles. Reportez-vous à la section 3 de la norme RFC 3986 pour obtenir la définition du domaine, de l'hôte, du chemin d'accès, de la requête, du schéma et des informations sur l'utilisateur mentionnées ci-dessous.
Règles de validation | |
---|---|
Schéma |
Les URI de redirection doivent utiliser le schéma HTTPS et non un protocole HTTP simple. Les URI Localhost (y compris les URI d'adresses IP localhost) ne sont pas concernés par cette règle. |
Hôte |
Les hôtes ne peuvent pas être des adresses IP brutes. Les adresses IP Localhost sont exemptées de cette règle. |
Domaine |
“googleusercontent.com” .goo.gl ), sauf si le domaine appartient à l'application. De plus, si une application qui possède un domaine de raccourcissement choisit de rediriger vers ce domaine, l'URI de redirection doit contenir “/google-callback/” dans son chemin ou se terminer par “/google-callback” . |
Informations sur l'utilisateur |
Les URI de redirection ne peuvent pas contenir le sous-composant "userinfo". |
Chemin d'accès |
Les URI de redirection ne peuvent pas contenir de traversée de répertoire (également appelée "suivi en arrière-plan du répertoire"), représenté par |
Requête |
Les URI de redirection ne peuvent pas contenir de redirections ouvertes. |
Fragment |
Les URI de redirection ne peuvent pas contenir le composant de fragment. |
Caractères |
Les URI de redirection ne peuvent pas contenir certains caractères, y compris les suivants :
|
Autorisation incrémentielle
Dans le protocole OAuth 2.0, votre application demande l'autorisation d'accéder aux ressources, qui sont identifiées par des champs d'application. Il est recommandé de demander l'autorisation de certaines ressources au moment où vous en avez besoin. Pour cela, le serveur d'autorisation de Google accepte les autorisations incrémentielles. Cette fonctionnalité vous permet de demander des niveaux d'accès selon vos besoins et, si l'utilisateur accorde l'autorisation pour le nouveau champ d'application, renvoie un code d'autorisation pouvant être échangé contre un jeton contenant tous les champs d'application que l'utilisateur a accordés au projet.
Par exemple, supposons qu'une application récupère les données de la chaîne YouTube de l'utilisateur authentifié et permette à l'utilisateur de récupérer les données YouTube Analytics via un flux spécial. Dans ce cas, au moment de la connexion, l'application peut demander l'accès uniquement au champ d'application https://www.googleapis.com/auth/youtube.force-ssl
. Toutefois, si l'utilisateur a tenté d'accéder aux données Analytics de sa chaîne, l'application peut également demander l'accès au champ d'application https://www.googleapis.com/auth/yt-analytics.readonly
.
Pour implémenter une autorisation incrémentielle, suivez la procédure normale de demande de jeton d'accès, mais assurez-vous que la demande d'autorisation inclut des champs d'application précédemment accordés. Cette approche permet à votre application d'éviter d'avoir à gérer plusieurs jetons d'accès.
Les règles suivantes s'appliquent à un jeton d'accès obtenu à partir d'une autorisation incrémentielle:
- Le jeton peut être utilisé pour accéder aux ressources correspondant à n'importe quel champ d'application déployé dans la nouvelle autorisation combinée.
- Lorsque vous utilisez le jeton d'actualisation pour l'autorisation combinée afin d'obtenir un jeton d'accès, le jeton d'accès représente l'autorisation combinée et peut être utilisé pour n'importe quelle valeur
scope
incluse dans la réponse. - L'autorisation combinée inclut tous les champs d'application que l'utilisateur a accordés au projet d'API, même si les autorisations ont été demandées auprès de différents clients. Par exemple, si un utilisateur a accordé l'accès à un champ d'application à l'aide du client de bureau d'une application, puis a accordé un autre champ d'application à la même application via un client mobile, l'autorisation combinée inclut les deux champs d'application.
- Si vous révoquez un jeton représentant une autorisation combinée, l'accès à tous les champs d'application de cette autorisation pour le compte de l'utilisateur associé est révoqué simultanément.
Les exemples de code spécifique à la langue à l'Étape 1: Définir les paramètres d'autorisation et l'exemple d'URL de redirection HTTP/REST à l'Étape 2 : Redirection vers le serveur OAuth 2.0 de Google utilisent tous une autorisation incrémentielle. Les exemples de code ci-dessous montrent également le code que vous devez ajouter pour utiliser l'autorisation incrémentielle.
PHP
$client->setIncludeGrantedScopes(true);
Python
En Python, définissez l'argument de mot clé include_granted_scopes
sur true
pour vous assurer qu'une requête d'autorisation inclut les champs d'application précédemment accordés. Il est possible que include_granted_scopes
ne soit pas le seul argument de mot clé que vous définissez, comme illustré dans l'exemple ci-dessous.
authorization_url, state = flow.authorization_url( # Enable offline access so that you can refresh an access token without # re-prompting the user for permission. Recommended for web server apps. access_type='offline', # Enable incremental authorization. Recommended as a best practice. include_granted_scopes='true')
Ruby
auth_client.update!( :additional_parameters => {"include_granted_scopes" => "true"} )
Node.js
const authorizationUrl = oauth2Client.generateAuthUrl({ // 'online' (default) or 'offline' (gets refresh_token) access_type: 'offline', /** Pass in the scopes array defined above. * Alternatively, if only one scope is needed, you can pass a scope URL as a string */ scope: scopes, // Enable incremental authorization. Recommended as a best practice. include_granted_scopes: true });
HTTP/REST
Dans cet exemple, l'application appelante demande l'accès pour récupérer les données YouTube de l'utilisateur en plus de tout autre accès que l'utilisateur a déjà accordé à l'application.
GET https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl& access_type=offline& state=security_token%3D138rk%3Btarget_url%3Dhttp...index& redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback& response_type=code& client_id=client_id& include_granted_scopes=true
Refreshing an access token (offline access)
Access tokens periodically expire and become invalid credentials for a related API request. You can refresh an access token without prompting the user for permission (including when the user is not present) if you requested offline access to the scopes associated with the token.
- If you use a Google API Client Library, the client object refreshes the access token as needed as long as you configure that object for offline access.
- If you are not using a client library, you need to set the
access_type
HTTP query parameter tooffline
when redirecting the user to Google's OAuth 2.0 server. In that case, Google's authorization server returns a refresh token when you exchange an authorization code for an access token. Then, if the access token expires (or at any other time), you can use a refresh token to obtain a new access token.
Requesting offline access is a requirement for any application that needs to access a Google
API when the user is not present. For example, an app that performs backup services or
executes actions at predetermined times needs to be able to refresh its access token when the
user is not present. The default style of access is called online
.
Server-side web applications, installed applications, and devices all obtain refresh tokens during the authorization process. Refresh tokens are not typically used in client-side (JavaScript) web applications.
PHP
If your application needs offline access to a Google API, set the API client's access type to
offline
:
$client->setAccessType("offline");
Une fois qu'un utilisateur a accordé un accès hors connexion aux niveaux d'accès demandés, vous pouvez continuer à utiliser le client API pour accéder aux API Google au nom de l'utilisateur lorsque celui-ci est hors connexion. L'objet client actualise le jeton d'accès si nécessaire.
Python
En Python, définissez l'argument de mot clé access_type
sur offline
pour vous assurer de pouvoir actualiser le jeton d'accès sans avoir à demander à nouveau l'autorisation à l'utilisateur. Il est possible que access_type
ne soit pas le seul argument de mot clé que vous définissez, comme illustré dans l'exemple ci-dessous.
authorization_url, state = flow.authorization_url( # Enable offline access so that you can refresh an access token without # re-prompting the user for permission. Recommended for web server apps. access_type='offline', # Enable incremental authorization. Recommended as a best practice. include_granted_scopes='true')
Une fois qu'un utilisateur a accordé un accès hors connexion aux niveaux d'accès demandés, vous pouvez continuer à utiliser le client API pour accéder aux API Google au nom de l'utilisateur lorsque celui-ci est hors connexion. L'objet client actualise le jeton d'accès si nécessaire.
Ruby
Si votre application a besoin d'un accès hors connexion à une API Google, définissez le type d'accès du client API sur offline
:
auth_client.update!( :additional_parameters => {"access_type" => "offline"} )
Une fois qu'un utilisateur a accordé un accès hors connexion aux niveaux d'accès demandés, vous pouvez continuer à utiliser le client API pour accéder aux API Google au nom de l'utilisateur lorsque celui-ci est hors connexion. L'objet client actualise le jeton d'accès si nécessaire.
Node.js
Si votre application a besoin d'un accès hors connexion à une API Google, définissez le type d'accès du client API sur offline
:
const authorizationUrl = oauth2Client.generateAuthUrl({ // 'online' (default) or 'offline' (gets refresh_token) access_type: 'offline', /** Pass in the scopes array defined above. * Alternatively, if only one scope is needed, you can pass a scope URL as a string */ scope: scopes, // Enable incremental authorization. Recommended as a best practice. include_granted_scopes: true });
Une fois qu'un utilisateur a accordé un accès hors connexion aux niveaux d'accès demandés, vous pouvez continuer à utiliser le client API pour accéder aux API Google au nom de l'utilisateur lorsque celui-ci est hors connexion. L'objet client actualise le jeton d'accès si nécessaire.
Les jetons d'accès expirent. Cette bibliothèque utilisera automatiquement un jeton d'actualisation pour obtenir un nouveau jeton d'accès s'il est sur le point d'expirer. Pour vous assurer de toujours stocker les jetons les plus récents, utilisez l'événement de jetons:
oauth2Client.on('tokens', (tokens) => { if (tokens.refresh_token) { // store the refresh_token in your secure persistent database console.log(tokens.refresh_token); } console.log(tokens.access_token); });
Cet événement de jetons ne se produit que lors de la première autorisation, et vous devez avoir défini votre access_type
sur offline
lorsque vous appelez la méthode generateAuthUrl
pour recevoir le jeton d'actualisation. Si vous avez déjà accordé à votre application les autorisations requises sans définir les contraintes appropriées pour la réception d'un jeton d'actualisation, vous devez à nouveau autoriser l'application pour recevoir un nouveau jeton d'actualisation.
Pour définir refresh_token
ultérieurement, vous pouvez utiliser la méthode setCredentials
:
oauth2Client.setCredentials({ refresh_token: `STORED_REFRESH_TOKEN` });
Une fois que le client dispose d'un jeton d'actualisation, les jetons d'accès sont obtenus et actualisés automatiquement lors du prochain appel à l'API.
HTTP/REST
Pour actualiser un jeton d'accès, votre application envoie une requête HTTPS POST
au serveur d'autorisation de Google (https://oauth2.googleapis.com/token
) qui inclut les paramètres suivants:
Champs | |
---|---|
client_id |
ID client obtenu à partir de API Console. |
client_secret |
Code secret du client obtenu à partir de API Console. |
grant_type |
Comme défini dans la spécification OAuth 2.0, la valeur de ce champ doit être définie sur refresh_token . |
refresh_token |
Jeton d'actualisation renvoyé par l'échange de code d'autorisation. |
L'extrait de code suivant présente un exemple de requête:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded client_id=your_client_id& client_secret=your_client_secret& refresh_token=refresh_token& grant_type=refresh_token
Tant que l'utilisateur n'a pas révoqué l'accès accordé à l'application, le serveur de jetons renvoie un objet JSON contenant un nouveau jeton d'accès. L'extrait de code suivant présente un exemple de réponse:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "scope": "https://www.googleapis.com/auth/drive.metadata.readonly", "token_type": "Bearer" }
Notez que le nombre de jetons d'actualisation qui seront émis est limité : une limite par combinaison client/utilisateur et une autre par utilisateur pour tous les clients. Nous vous conseillons d'enregistrer les jetons d'actualisation dans un espace de stockage à long terme et de continuer à les utiliser tant qu'ils restent valides. Si votre application demande trop de jetons d'actualisation, elle peut dépasser ces limites, auquel cas les jetons d'actualisation plus anciens cesseront de fonctionner.
Révoquer un jeton
Dans certains cas, un utilisateur peut souhaiter révoquer l'accès accordé à une application. Un utilisateur peut révoquer l'accès dans les paramètres du compte. Pour en savoir plus, consultez la section Supprimer l'accès à un site ou une application de la documentation d'assistance "Applications et sites tiers ayant accès à votre compte".
Une application peut également révoquer de manière programmatique l'accès qui lui est accordé. La révocation programmatique est importante dans les cas où un utilisateur se désabonne, supprime une application ou si les ressources d'API requises par une application ont changé de manière significative. En d'autres termes, une partie du processus de suppression peut inclure une requête API pour s'assurer que les autorisations précédemment accordées à l'application sont supprimées.
PHP
Pour révoquer un jeton de manière programmatique, appelez revokeToken()
:
$client->revokeToken();
Python
Pour révoquer un jeton de manière programmatique, envoyez une requête à https://oauth2.googleapis.com/revoke
qui inclut le jeton en tant que paramètre et définit l'en-tête Content-Type
:
requests.post('https://oauth2.googleapis.com/revoke', params={'token': credentials.token}, headers = {'content-type': 'application/x-www-form-urlencoded'})
Ruby
Pour révoquer un jeton de manière automatisée, envoyez une requête HTTP au point de terminaison oauth2.revoke
:
uri = URI('https://oauth2.googleapis.com/revoke') response = Net::HTTP.post_form(uri, 'token' => auth_client.access_token)
Il peut s'agir d'un jeton d'accès ou d'un jeton d'actualisation. Si le jeton est un jeton d'accès et qu'il possède un jeton d'actualisation correspondant, il sera également révoqué.
Si la révocation a bien été traitée, le code d'état de la réponse est 200
. Pour les conditions d'erreur, un code d'état 400
est renvoyé avec un code d'erreur.
Node.js
Pour révoquer un jeton de manière automatisée, envoyez une requête HTTPS POST au point de terminaison /revoke
:
const https = require('https'); // Build the string for the POST request let postData = "token=" + userCredential.access_token; // Options for POST request to Google's OAuth 2.0 server to revoke a token let postOptions = { host: 'oauth2.googleapis.com', port: '443', path: '/revoke', method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded', 'Content-Length': Buffer.byteLength(postData) } }; // Set up the request const postReq = https.request(postOptions, function (res) { res.setEncoding('utf8'); res.on('data', d => { console.log('Response: ' + d); }); }); postReq.on('error', error => { console.log(error) }); // Post the request with data postReq.write(postData); postReq.end();
Le paramètre de jeton peut être un jeton d'accès ou un jeton d'actualisation. Si le jeton est un jeton d'accès et qu'il possède un jeton d'actualisation correspondant, il sera également révoqué.
Si la révocation a bien été traitée, le code d'état de la réponse est 200
. Pour les conditions d'erreur, un code d'état 400
est renvoyé avec un code d'erreur.
HTTP/REST
Pour révoquer un jeton de manière automatisée, votre application envoie une requête à https://oauth2.googleapis.com/revoke
et inclut le jeton en tant que paramètre:
curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \ https://oauth2.googleapis.com/revoke?token={token}
Il peut s'agir d'un jeton d'accès ou d'un jeton d'actualisation. Si le jeton est un jeton d'accès et qu'il possède un jeton d'actualisation correspondant, il sera également révoqué.
Si la révocation a bien été traitée, le code d'état HTTP de la réponse est 200
. Pour les conditions d'erreur, un code d'état HTTP 400
est renvoyé avec un code d'erreur.