Ce document explique comment les applications de serveurs 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 afin d'accéder aux API Google.
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 des utilisateurs pour stocker des fichiers dans leurs Drive.
Ce parcours OAuth 2.0 est spécifiquement destiné à l'autorisation utilisateur. Elle est conçue pour les applications pouvant stocker des informations confidentielles et conserver leur état. Une application de serveur Web autorisée peut accéder à une API pendant que l'utilisateur interagit avec l'application ou quand il la quitte.
Les applications de serveur Web utilisent également fréquemment des comptes de service pour autoriser les requêtes API, en particulier lors de l'appel d'API Cloud pour accéder à des données basées sur un projet plutôt qu'à celles spécifiques à l'utilisateur. Les applications de serveur Web peuvent utiliser les comptes de service conjointement avec l'autorisation de l'utilisateur.
Bibliothèques clientes
Les exemples propres au langage présentés sur cette page utilisent les bibliothèques clientes des API Google pour intégrer l'autorisation OAuth 2.0. Pour exécuter les exemples de code, vous devez d'abord installer la bibliothèque cliente associée à votre langage.
Lorsque vous gérez le flux OAuth 2.0 de votre application à l'aide d'une bibliothèque cliente des API Google, celle-ci effectue de nombreuses actions que l'application devrait gérer elle-même. Par exemple, elle détermine quand l'application peut utiliser ou actualiser les jetons d'accès stockés, et quand l'application doit obtenir le consentement de l'utilisateur. La bibliothèque cliente génère également des URL de redirection correctes et met 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:
Prerequisites
Activer les API pour votre projet.
Toute application qui appelle les 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.
- API Library répertorie toutes les API disponibles, regroupées par famille de produits et classées en fonction de leur popularité. Si l'API que vous souhaitez activer n'est pas visible dans la liste, recherchez-la ou cliquez sur Tout afficher dans la famille de produits à laquelle elle appartient.
- Sélectionnez l'API que vous souhaitez activer, puis cliquez sur le bouton Activer.
- If prompted, enable billing.
- If prompted, read and accept the API's Terms of Service.
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 sur le serveur OAuth 2.0 de Google. Les étapes suivantes expliquent comment créer des identifiants pour votre projet. Vos applications peuvent ensuite utiliser les 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 Web 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 les 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
. Sachez 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 pour qu'elle n'affiche pas les codes d'autorisation pour 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 en toute sécurité dans un emplacement accessible uniquement par votre application.
Identifier les niveaux d'accès
Les champs d'application permettent à votre application de demander l'accès aux ressources dont elle a besoin tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils peuvent accorder à votre application. Par conséquent, 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 à mettre en œuvre l'autorisation OAuth 2.0, nous vous recommandons d'identifier les niveaux d'accès requis pour votre application.
Nous vous recommandons également de demander à votre application d'accéder 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 permet aux utilisateurs de comprendre plus facilement pourquoi votre application a besoin d'accéder à cette application.
Le document Champs d'application de l'API OAuth 2.0 contient une liste complète des champs d'application que vous pouvez utiliser pour accéder aux API Google.
Exigences en fonction du langage
Pour exécuter les exemples de code de 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 au langage ci-dessous.
PHP
Pour exécuter les exemples de code PHP dans ce document, vous devez disposer des éléments suivants:
- PHP 5.4 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:
php composer.phar require google/apiclient:^2.0
Python
Pour exécuter les exemples de code Python dans ce document, vous devez disposer:
- Python 2.6 ou version ultérieure
- L'outil de gestion des packages pip.
- Bibliothèque cliente des API Google pour Python :
pip install --upgrade google-api-python-client
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'application Web Python Flask.
pip install --upgrade flask
- Bibliothèque HTTP
requests
pip install --upgrade requests
Ruby
Pour exécuter les exemples de code Ruby dans ce document, vous devez disposer des éléments suivants:
- Ruby 2.2.2 ou version ultérieure
-
Bibliothèque cliente des API Google pour Ruby:
gem install google-api-client
-
Le framework d'applications Web Sinatra Ruby.
gem install sinatra
Node.js
Pour exécuter les exemples de code Node.js dans ce document, vous devez disposer des éléments suivants:
- LTS de maintenance, LTS actif ou version actuelle de Node.js.
-
Le client Node.js des API Google:
npm install googleapis
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
La procédure suivante montre comment votre application interagit avec le serveur OAuth 2.0 de Google pour obtenir le consentement d'un utilisateur afin d'exécuter une requête API pour le compte de l'utilisateur. Votre application doit disposer de ce consentement pour pouvoir exécuter une requête API Google nécessitant une autorisation utilisateur.
La liste ci-dessous récapitule rapidement 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 choisi.
- Si l'utilisateur a accordé les autorisations demandées, votre application récupère les jetons requis 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 et définissent les autorisations que l'utilisateur sera invité à accorder.
- Si vous utilisez une bibliothèque cliente Google pour l'authentification et l'autorisation OAuth 2.0, vous devez créer et configurer un objet qui définit ces paramètres.
- Si vous appelez directement le point de terminaison Google OAuth 2.0, vous générerez une URL et définirez les paramètres sur cette URL.
Les onglets ci-dessous définissent les paramètres d'autorisation acceptés pour les applications de serveurs Web. Les exemples propres au langage illustrent également comment utiliser une bibliothèque cliente ou une bibliothèque d'autorisations 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 utilise les informations de votre fichier client_secret.json pour identifier votre application. (Pour en savoir plus sur ce fichier, consultez Créer des identifiants d'autorisation.) L'objet identifie également les niveaux d'accès demandés par votre application 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 access_type
et include_granted_scopes
facultatifs.
Par exemple, ce code nécessite un accès en lecture seule, hors connexion, à l'interface Google Drive d'un utilisateur:
$client = new Google_Client(); $client->setAuthConfig('client_secret.json'); $client->addScope(Google_Service_Drive::DRIVE_METADATA_READONLY); $client->setRedirectUri('http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php'); // 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'); // Using "consent" ensures that your application always receives a refresh token. // If you are not using offline access, you can omit this. $client->setApprovalPrompt("consent"); $client->setIncludeGrantedScopes(true); // incremental auth
La requête spécifie les informations suivantes:
Paramètres | |||||||
---|---|---|---|---|---|---|---|
client_id |
Obligatoire
ID client de votre application. Vous pouvez trouver cette valeur dans le API ConsoleCredentials page. Dans PHP, appelez la fonction $client = new Google_Client(); $client->setAuthConfig('client_secret.json'); |
||||||
redirect_uri |
Obligatoire
Détermine où le serveur d'API redirige l'utilisateur une fois que l'utilisateur a terminé le parcours 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 API ConsoleCredentials page. Si cette valeur ne correspond pas à un URI de redirection autorisé pour le Notez que le schéma Pour définir cette valeur en PHP, appelez la fonction $client->setRedirectUri('https://oauth2.example.com/code'); |
||||||
scope |
Obligatoire
Liste de champs d'application délimitée par des espaces qui identifient les ressources auxquelles votre application peut accéder au nom de l'utilisateur. Ces valeurs indiquent l'écran de consentement que Google affiche à l'utilisateur. Les champs d'application permettent à votre application de demander l'accès aux ressources dont elle a besoin tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils peuvent accorder à votre application. Par conséquent, il existe une relation inverse entre le nombre de champs d'application demandés et la probabilité d'obtenir le consentement de l'utilisateur. Pour définir cette valeur en PHP, appelez la fonction $client->addScope(Google_Service_Drive::DRIVE_METADATA_READONLY); Dans la mesure du possible, nous vous recommandons de demander à votre application d'accéder aux champs d'application des autorisations. En demandant aux utilisateurs d'accéder aux données utilisateur en contexte via une autorisation incrémentielle, vous les aidez à comprendre plus facilement pourquoi votre application a besoin d'accéder à ces données. |
||||||
access_type |
Approche conseillée
Indique si votre application peut actualiser les jetons d'accès lorsque l'utilisateur n'est pas présent dans le navigateur. Les valeurs valides sont Définissez la valeur sur Pour définir cette valeur en PHP, appelez la fonction $client->setAccessType('offline'); |
||||||
state |
Approche conseillée
Spécifie toute valeur de chaîne que votre application utilise pour maintenir l'état entre votre requête 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 à diverses fins, par exemple pour rediriger l'utilisateur vers la ressource appropriée de votre application, pour envoyer des nonces et pour atténuer la falsification de requêtes intersites. Étant donné que la valeur Pour définir cette valeur en PHP, appelez la fonction $client->setState($sample_passthrough_value); |
||||||
include_granted_scopes |
Facultatif
Permet aux applications d'utiliser une autorisation incrémentielle pour demander l'accès à des niveaux d'accès supplémentaires en contexte. Si vous définissez la valeur de ce paramètre sur Pour définir cette valeur en PHP, appelez la fonction $client->setIncludeGrantedScopes(true); |
||||||
login_hint |
Facultatif
Si votre application sait quel utilisateur tente d'authentifier, elle peut utiliser ce paramètre pour fournir une indication au serveur Google Authentication. Le serveur utilise l'indice pour simplifier le flux de connexion en préremplissant le champ d'adresse e-mail dans le formulaire de connexion ou en sélectionnant la session de connexion multicompte appropriée. Définissez la valeur du paramètre sur une adresse e-mail ou un identifiant Pour définir cette valeur en PHP, appelez la fonction $client->setLoginHint('None'); |
||||||
prompt |
Facultatif
Liste d'invites séparées par un espace et sensible à la casse, destinées à présenter l'utilisateur. Si vous ne spécifiez pas ce paramètre, l'utilisateur n'est invité que la première fois que votre projet demande l'accès. Pour en savoir plus, consultez la section Demander le nouveau consentement. Pour définir cette valeur en PHP, appelez la fonction $client->setApprovalPrompt('consent'); Les valeurs possibles sont les suivantes :
|
Python
L'extrait de code suivant utilise le module google-auth-oauthlib.flow
pour créer la requête d'autorisation.
Le code crée 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 niveaux d'accès demandés par votre application 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 access_type
et include_granted_scopes
facultatifs.
Par exemple, ce code nécessite un accès en lecture seule, hors connexion, à l'interface Google Drive d'un utilisateur:
import google.oauth2.credentials import google_auth_oauthlib.flow # Use the client_secret.json file to identify the application requesting # authorization. The client ID (from that file) and access scopes are required. flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file( 'client_secret.json', scopes=['https://www.googleapis.com/auth/drive.metadata.readonly']) # 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( # 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')
La requête spécifie les informations suivantes:
Paramètres | |||||||
---|---|---|---|---|---|---|---|
client_id |
Obligatoire
ID client de votre application. Vous pouvez trouver cette valeur dans le API ConsoleCredentials page. Dans Python, appelez la méthode flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file( 'client_secret.json', scopes=['https://www.googleapis.com/auth/drive.metadata.readonly']) |
||||||
redirect_uri |
Obligatoire
Détermine où le serveur d'API redirige l'utilisateur une fois que l'utilisateur a terminé le parcours 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 API ConsoleCredentials page. Si cette valeur ne correspond pas à un URI de redirection autorisé pour le Notez que le schéma Pour définir cette valeur en Python, définissez la propriété flow.redirect_uri = 'https://oauth2.example.com/code' |
||||||
scope |
Obligatoire
Liste des champs d'application qui identifient les ressources auxquelles votre application peut accéder au nom de l'utilisateur. Ces valeurs indiquent l'écran de consentement que Google affiche à l'utilisateur. Les champs d'application permettent à votre application de demander l'accès aux ressources dont elle a besoin tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils peuvent accorder à votre application. Par conséquent, il existe une relation inverse entre le nombre de champs d'application demandés et la probabilité d'obtenir le consentement de l'utilisateur. Dans Python, utilisez la même méthode que pour définir la liste de champs d'application flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file( 'client_secret.json', scopes=['https://www.googleapis.com/auth/drive.metadata.readonly']) Dans la mesure du possible, nous vous recommandons de demander à votre application d'accéder aux champs d'application des autorisations. En demandant aux utilisateurs d'accéder aux données utilisateur en contexte via une autorisation incrémentielle, vous les aidez à comprendre plus facilement pourquoi votre application a besoin d'accéder à ces données. |
||||||
access_type |
Approche conseillée
Indique si votre application peut actualiser les jetons d'accès lorsque l'utilisateur n'est pas présent dans le navigateur. Les valeurs valides sont Définissez la valeur sur Dans Python, définissez le paramètre authorization_url, state = flow.authorization_url( access_type='offline', include_granted_scopes='true') |
||||||
state |
Approche conseillée
Spécifie toute valeur de chaîne que votre application utilise pour maintenir l'état entre votre requête 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 à diverses fins, par exemple pour rediriger l'utilisateur vers la ressource appropriée de votre application, pour envoyer des nonces et pour atténuer la falsification de requêtes intersites. Étant donné que la valeur Dans Python, définissez le paramètre authorization_url, state = flow.authorization_url( access_type='offline', state=sample_passthrough_value, include_granted_scopes='true') |
||||||
include_granted_scopes |
Facultatif
Permet aux applications d'utiliser une autorisation incrémentielle pour demander l'accès à des niveaux d'accès supplémentaires en contexte. Si vous définissez la valeur de ce paramètre sur Dans Python, définissez le paramètre authorization_url, state = flow.authorization_url( access_type='offline', include_granted_scopes='true') |
||||||
login_hint |
Facultatif
Si votre application sait quel utilisateur tente d'authentifier, elle peut utiliser ce paramètre pour fournir une indication au serveur Google Authentication. Le serveur utilise l'indice pour simplifier le flux de connexion en préremplissant le champ d'adresse e-mail dans le formulaire de connexion ou en sélectionnant la session de connexion multicompte appropriée. Définissez la valeur du paramètre sur une adresse e-mail ou un identifiant Dans Python, définissez le paramètre authorization_url, state = flow.authorization_url( access_type='offline', login_hint='None', include_granted_scopes='true') |
||||||
prompt |
Facultatif
Liste d'invites séparées par un espace et sensible à la casse, destinées à présenter l'utilisateur. Si vous ne spécifiez pas ce paramètre, l'utilisateur n'est invité que la première fois que votre projet demande l'accès. Pour en savoir plus, consultez la section Demander le nouveau consentement. Dans Python, définissez le paramètre authorization_url, state = flow.authorization_url( access_type='offline', prompt='consent', include_granted_scopes='true') Les valeurs possibles sont les suivantes :
|
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 champs d'application 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, ce code nécessite un accès en lecture seule, hors connexion, à l'interface Google Drive d'un utilisateur:
require 'google/apis/drive_v2' require 'google/api_client/client_secrets' client_secrets = Google::APIClient::ClientSecrets.load auth_client = client_secrets.to_authorization auth_client.update!( :scope => 'https://www.googleapis.com/auth/drive.metadata.readonly', :redirect_uri => 'http://www.example.com/oauth2callback', :additional_parameters => { "access_type" => "offline", # offline access "include_granted_scopes" => "true" # incremental auth } )
Votre application utilise l'objet client pour effectuer les opérations OAuth 2.0, telles que la génération d'URL de requête d'autorisation et l'application de jetons d'accès aux requêtes HTTP.
Node.js
L'extrait de code ci-dessous crée un objet google.auth.OAuth2
, qui définit les paramètres de la requête d'autorisation.
Cet objet utilise les informations de votre fichier client_secret.json pour identifier votre application. Pour demander les autorisations d'un utilisateur à récupérer un jeton d'accès, vous le redirigez vers une page d'autorisation. Pour créer une URL de page d'autorisation:
const {google} = require('googleapis'); /** * 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 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 });
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 situé à https://accounts.google.com/o/oauth2/v2/auth
. Ce point de terminaison n'est accessible que via HTTPS. Les connexions HTTP simples 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 pouvez trouver cette valeur dans le API ConsoleCredentials page. |
||||||
redirect_uri |
Obligatoire
Détermine où le serveur d'API redirige l'utilisateur une fois que l'utilisateur a terminé le parcours 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 API ConsoleCredentials page. Si cette valeur ne correspond pas à un URI de redirection autorisé pour le 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ée par des espaces qui identifient les ressources auxquelles votre application peut accéder au nom de l'utilisateur. Ces valeurs indiquent l'écran de consentement que Google affiche à l'utilisateur. Les champs d'application permettent à votre application de demander l'accès aux ressources dont elle a besoin tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils peuvent accorder à votre application. Par conséquent, il existe une relation inverse entre le nombre de champs d'application demandés et la probabilité d'obtenir le consentement de l'utilisateur. Dans la mesure du possible, nous vous recommandons de demander à votre application d'accéder aux champs d'application des autorisations. En demandant aux utilisateurs d'accéder aux données utilisateur en contexte via une autorisation incrémentielle, vous les aidez à comprendre plus facilement pourquoi votre application a besoin d'accéder à ces données. |
||||||
access_type |
Approche conseillée
Indique si votre application peut actualiser les jetons d'accès lorsque l'utilisateur n'est pas présent dans le navigateur. Les valeurs valides sont Définissez la valeur sur |
||||||
state |
Approche conseillée
Spécifie toute valeur de chaîne que votre application utilise pour maintenir l'état entre votre requête 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 à diverses fins, par exemple pour rediriger l'utilisateur vers la ressource appropriée de votre application, pour envoyer des nonces et pour atténuer la falsification de requêtes intersites. Étant donné que la valeur |
||||||
include_granted_scopes |
Facultatif
Permet aux applications d'utiliser une autorisation incrémentielle pour demander l'accès à des niveaux d'accès supplémentaires en contexte. Si vous définissez la valeur de ce paramètre sur |
||||||
login_hint |
Facultatif
Si votre application sait quel utilisateur tente d'authentifier, elle peut utiliser ce paramètre pour fournir une indication au serveur Google Authentication. Le serveur utilise l'indice pour simplifier le flux de connexion en préremplissant le champ d'adresse e-mail dans le formulaire de connexion ou en sélectionnant la session de connexion multicompte appropriée. Définissez la valeur du paramètre sur une adresse e-mail ou un identifiant |
||||||
prompt |
Facultatif
Liste d'invites séparées par un espace et sensible à la casse, destinées à présenter l'utilisateur. Si vous ne spécifiez pas ce paramètre, l'utilisateur n'est invité que la première fois que votre projet demande l'accès. Pour en savoir plus, consultez la section Demander le nouveau consentement. Les valeurs possibles sont les suivantes :
|
É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. Cela se produit généralement lorsque votre application doit d'abord accéder aux données de l'utilisateur. Dans le cas de l'autorisation incrémentielle, cette étape se produit également lorsque votre application doit d'abord accéder à des ressources supplémentaires auxquelles elle n'a pas encore l'autorisation d'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'applications 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 = auth_client.authorization_uri.to_s
- Rediriger l'utilisateur vers
auth_uri
Node.js
-
Utilisez l'URL générée
authorizationUrl
à partir de la méthode Étape 1generateAuthUrl
pour demander l'accès au serveur OAuth 2.0 de Google. -
Rediriger l'utilisateur vers
authorizationUrl
res.writeHead(301, { "Location": authorizationUrl });
HTTP/REST
Sample redirect to Google's authorization server
An example URL is shown below, with line breaks and spaces for readability.
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly& access_type=offline& include_granted_scopes=true& response_type=code& state=state_parameter_passthrough_value& redirect_uri=https%3A//oauth2.example.com/code& client_id=client_id
Après avoir créé l'URL de la requête, redirigez-le vers lui.
Le serveur OAuth 2.0 de Google authentifie l'utilisateur et obtient le consentement de celui-ci pour que votre application puisse accéder aux champs d'application demandés. La réponse est renvoyée à votre application avec l'URL de redirection que vous avez spécifiée.
Étape 3: Google demande l'autorisation à l'utilisateur
Dans cette étape, l'utilisateur décide d'accorder ou non l'accès à votre application. À ce stade, Google affiche une fenêtre de consentement indiquant le nom de votre application et les services d'API Google auxquels elle demande l'autorisation d'accéder avec les identifiants d'autorisation de l'utilisateur, ainsi qu'un résumé des champs d'application à accorder. L'utilisateur peut ensuite accepter d'accorder l'accès à un ou plusieurs niveaux d'accès demandés par votre application ou refuser la demande.
À ce stade, votre application n'a rien à faire, 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 visibles par les 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 niveaux d'accès demandés en raison des règles de leur administrateur Google Workspace. Pour savoir comment un administrateur peut restreindre l'accès à tous les champs d'application ou les niveaux d'accès sensibles et restreints jusqu'à ce que l'accès soit explicitement accordé à votre ID client OAuth, consultez l'article d'aide destiné aux administrateurs Google Workspace Contrôler les applications tierces et les données internes ayant accès aux données Google Workspace.
disallowed_useragent
Le point de terminaison de l'autorisation est affiché dans un user-agent intégré interdit par les règles OAuth 2.0 de Google.
Android
Les développeurs Android peuvent rencontrer ce message d'erreur lorsqu'ils ouvrent des demandes d'autorisation dans android.webkit.WebView
.
Les développeurs doivent utiliser des bibliothèques Android telles que Google Sign-In pour Android ou OpenID Foundation pour AppAuth pour Android.
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 et l'application par défaut du navigateur. La bibliothèque Android Custom Tabs est également disponible.
iOS
Les développeurs iOS et macOS peuvent rencontrer cette erreur lors de l'ouverture des demandes d'autorisation dans WKWebView
.
Les développeurs doivent utiliser des bibliothèques iOS comme Google Sign-In pour iOS ou OpenID Foundation pour AppAuth pour iOS.
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 que l'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 comprend à la fois les gestionnaires Universal Links et l'application de navigateur par défaut. La bibliothèque SFSafariViewController
est également une option compatible.
org_internal
L'ID client OAuth dans 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 la page "Configurer votre autorisation OAuth"
redirect_uri_mismatch
Le redirect_uri
transmis dans la requête d'autorisation ne correspond pas à un URI de redirection autorisé pour l'ID client OAuth. Examinez les URI de redirection autorisés dans Google API Console Credentials page.
Étape 4: Gérez la réponse du serveur OAuth 2.0
Le serveur OAuth 2.0 répond à votre demande d'accès à l'aide de 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 en cas d'erreur:
https://oauth2.example.com/auth?error=access_denied
Réponse au 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'exemple d'URL suivant, qui demande un accès en lecture seule pour afficher les métadonnées des fichiers dans votre Google Drive:
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly& access_type=offline& include_granted_scopes=true& response_type=code& state=state_parameter_passthrough_value& redirect_uri=https%3A//oauth2.example.com/code& client_id=client_id
Après avoir terminé le parcours OAuth 2.0, vous devriez être redirigé vers http://localhost/oauth2callback
, 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: Code d'autorisation Exchange pour les 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 à l'aide de la méthode getAccessToken
:
$access_token = $client->getAccessToken();
Python
Sur votre page de rappel, utilisez la bibliothèque google-auth
pour valider la réponse du serveur d'autorisation. Ensuite, utilisez la méthode flow.fetch_token
pour échanger le code d'autorisation dans 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/drive.metadata.readonly'], 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
Pour échanger un code d'autorisation contre un jeton d'accès, utilisez la méthode fetch_access_token!
:
auth_client.code = auth_code auth_client.fetch_access_token!
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. if (req.url.startsWith('/oauth2callback')) { // Handle the OAuth 2.0 server response let q = url.parse(req.url, true).query; // 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 indiqué dans la spécification OAuth 2.0, la valeur de ce champ doit être définie sur authorization_code . |
redirect_uri |
Un des URI de redirection répertoriés pour votre projet dans le API ConsoleCredentials page pour 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
Pour répondre à cette requête, Google renvoie 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 sur le serveur d'autorisation de Google.
La réponse contient les champs suivants :
Champs | |
---|---|
access_token |
Jeton que votre application envoie 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 avez défini le paramètre access_type sur offline dans la requête initiale au serveur d'autorisation de Google.
|
scope |
Champs d'application d'accès accordés par access_token , exprimés sous forme de liste sensible à la casse. |
token_type |
Type de jeton renvoyé. Pour l'instant, la valeur de ce champ est toujours définie sur Bearer . |
L'extrait de code suivant illustre un exemple de réponse:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/drive.metadata.readonly", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
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, fournissez un objet
Google_Client
autorisé au constructeur de l'API que vous souhaitez appeler. Par exemple, pour appeler l'API Drive, procédez comme suit :$drive = new Google_Service_Drive($client);
- Envoyez des requêtes au service d'API à l'aide de l'interface fournie par l'objet de service.
Par exemple, pour répertorier les fichiers dans Google Drive de l'utilisateur authentifié :
$files = $drive->files->listFiles(array())->getItems();
Python
Une fois que vous avez obtenu un jeton d'accès, votre application peut l'utiliser pour autoriser 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. 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 et les identifiants utilisateur : par exemple, pour appeler la version 2 de l'API Drive :from googleapiclient.discovery import build drive = build('drive', 'v2', credentials=credentials)
- Envoyez des requêtes au service d'API à l'aide de l'interface fournie par l'objet de service.
Par exemple, pour répertorier les fichiers dans Google Drive de l'utilisateur authentifié :
files = drive.files().list().execute()
Ruby
Utilisez l'objet auth_client
pour appeler les API Google en procédant comme suit:
- Créez un objet de service pour l'API que vous souhaitez appeler.
Par exemple, pour appeler la version 2 de l'API Drive :
drive = Google::Apis::DriveV2::DriveService.new
- Définissez les identifiants sur le service :
drive.authorization = auth_client
- Envoyez des requêtes au service d'API à l'aide de l'interface fournie par l'objet de service.
Par exemple, pour lister les fichiers Google Drive des utilisateurs authentifiés :
files = drive.list_files
Vous pouvez également accorder l'autorisation méthode par méthode en fournissant le paramètre options
à une méthode:
files = drive.list_files(options: { authorization: auth_client })
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 des requêtes API pour le compte 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 des API Google au nom d'un compte utilisateur donné, si le ou les niveaux d'accès requis par l'API vous 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, il est préférable d'utiliser l'en-tête HTTP, car les chaînes de requête sont généralement 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 Drive Files).
Vous pouvez essayer toutes les API Google et en consulter la portée sur OAuth 2.0 Playground.
Exemples de requêtes HTTP GET
Un appel vers le point de terminaison drive.files
(API Drive Files) à 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 /drive/v2/files HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
Voici un appel vers 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/drive/v2/files?access_token=access_token
Exemples curl
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 (méthode recommandée):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files
Vous pouvez également sélectionner l'option du paramètre de chaîne de requête:
curl https://www.googleapis.com/drive/v2/files?access_token=access_token
Exemple complet
L'exemple suivant affiche une liste de fichiers au format JSON dans le Google Drive d'un utilisateur une fois qu'il s'est authentifié et autorise l'application à accéder aux métadonnées Drive de l'utilisateur.
PHP
Pour exécuter cet exemple:
- Dans 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 modifiez-le. 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.0
- 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.4 ou une version ultérieure, vous pouvez utiliser le serveur Web test intégré 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_Drive::DRIVE_METADATA_READONLY); if (isset($_SESSION['access_token']) && $_SESSION['access_token']) { $client->setAccessToken($_SESSION['access_token']); $drive = new Google_Service_Drive($client); $files = $drive->files->listFiles(array())->getItems(); echo json_encode($files); } 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_Drive::DRIVE_METADATA_READONLY); if (! isset($_GET['code'])) { $auth_url = $client->createAuthUrl(); header('Location: ' . filter_var($auth_url, FILTER_SANITIZE_URL)); } else { $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 à 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 pointe 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 le flux d'authentification directement : ce lien redirige vers une page qui tente d'envoyer l'utilisateur à l'aide du 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 renvoie vers 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é l'autorisation à votre application tentait d'exécuter une requête API dans une nouvelle session. Cette page vous permet également de voir la réponse d'API que votre application obtiendrait si un utilisateur a révoqué des autorisations accordées à votre application, et que votre application a toujours essayé 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/drive.metadata.readonly'] API_SERVICE_NAME = 'drive' API_VERSION = 'v2' 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']) drive = googleapiclient.discovery.build( API_SERVICE_NAME, API_VERSION, credentials=credentials) files = drive.files().list().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(**files) @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/drive_v2' require 'google/api_client/client_secrets' require 'json' require 'sinatra' enable :sessions set :session_secret, 'setme' get '/' do unless session.has_key?(:credentials) redirect to('/oauth2callback') end client_opts = JSON.parse(session[:credentials]) auth_client = Signet::OAuth2::Client.new(client_opts) drive = Google::Apis::DriveV2::DriveService.new files = drive.list_files(options: { authorization: auth_client }) "<pre>#{JSON.pretty_generate(files.to_h)}</pre>" end get '/oauth2callback' do client_secrets = Google::APIClient::ClientSecrets.load auth_client = client_secrets.to_authorization auth_client.update!( :scope => 'https://www.googleapis.com/auth/drive.metadata.readonly', :redirect_uri => url('/oauth2callback')) if request['code'] == nil auth_uri = auth_client.authorization_uri.to_s redirect to(auth_uri) else auth_client.code = request['code'] auth_client.fetch_access_token! auth_client.client_secret = nil session[:credentials] = auth_client.to_json redirect to('/') end end
Node.js
Pour exécuter cet exemple:
-
Dans API Console, ajoutez l'URL de la machine locale à la liste des URL de redirection. Par exemple, ajoutez
http://localhost
. - Assurez-vous que la version LTS de maintenance, la version LTS active ou la version actuelle de Node.js sont installées.
-
Créez un répertoire et modifiez-le. 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 suivant :
node .\main.js
main.js
const http = require('http'); const https = require('https'); const url = require('url'); const { google } = require('googleapis'); /** * 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' ]; // 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 }); /* 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 server = http.createServer(async function (req, res) { // Example on redirecting user to Google's OAuth 2.0 server. if (req.url == '/') { res.writeHead(301, { "Location": authorizationUrl }); } // Receive the callback from Google's OAuth 2.0 server. if (req.url.startsWith('/oauth2callback')) { // 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 { // 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 if (req.url == '/revoke') { // 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(); } res.end(); }).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/drive.metadata.readonly' 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://www.googleapis.com/drive/v2/files' r = requests.get(req_uri, headers=headers) return r.text @app.route('/oauth2callback') def oauth2callback(): if 'code' not in flask.request.args: auth_uri = ('https://accounts.google.com/o/oauth2/v2/auth?response_type=code' '&client_id={}&redirect_uri={}&scope={}').format(CLIENT_ID, REDIRECT_URI, SCOPE) return flask.redirect(auth_uri) else: 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 de permettre aux développeurs de sécuriser leurs applications. Vos URI de redirection doivent respecter ces règles. Consultez la section 3 de la documentation 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 utilisateur, mentionnés ci-dessous.
Règles de validation | |
---|---|
Schéma |
Les URI de redirection doivent utiliser le schéma HTTPS, et non HTTP simple. Les URI Localhost (y compris les URI d'adresse IP de l'hôte local) sont exemptés de cette règle. |
Organisateur |
Les hôtes ne peuvent pas être des adresses IP brutes. Les adresses IP Localhost ne sont pas concernées par cette règle. |
Domaine |
“googleusercontent.com” .goo.gl ), sauf si l'application est propriétaire du domaine. De plus, si une application propriétaire d'un domaine plus court décide de rediriger vers ce domaine, cette URI de redirection doit contenir “/google-callback/” dans son chemin ou se terminer par “/google-callback” . |
Infos 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 balayage de chemin, également appelé "suivi des répertoires", représenté par un |
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 :
|
Autorisation incrémentielle
Dans le protocole OAuth 2.0, votre application demande l'autorisation d'accéder aux ressources, identifiées par des champs d'application. Il est recommandé d'offrir une expérience utilisateur de manière optimale pour demander une autorisation pour les ressources au moment où vous en avez besoin. Cette fonctionnalité est disponible sur le serveur d'autorisation de Google. Cette fonctionnalité vous permet de demander les champs d'application en fonction des besoins et, si l'utilisateur accorde les autorisations nécessaires, renvoie un code d'autorisation pouvant être échangé contre un jeton contenant tous les champs d'application accordés par l'utilisateur.
Par exemple, une application qui permet aux utilisateurs d'écouter des titres et de créer des mix peut nécessiter très peu de ressources au moment de la connexion, peut-être rien de plus que le nom de la personne qui se connecte. Toutefois, pour enregistrer un mix terminé, il faudra accéder à leur Google Drive. La plupart des utilisateurs trouveront naturellement que l'accès à Google Drive est demandé uniquement au moment où l'application en a réellement besoin.
Dans ce cas, au moment de la connexion, l'application peut demander les champs d'application openid
et profile
pour effectuer une connexion de base, puis demander le champ d'application https://www.googleapis.com/auth/drive.file
au moment de la première requête pour enregistrer un mix.
Pour mettre en œuvre une autorisation incrémentielle, vous devez suivre le flux normal pour demander un jeton d'accès, mais vous assurer que la demande d'autorisation inclut les niveaux d'accès précédemment accordés. Cette approche permet à votre application d'éviter de 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 à l'une des habilitations déployées dans la nouvelle autorisation combinée.
- Lorsque vous utilisez le jeton d'actualisation pour obtenir l'autorisation combinée, le jeton d'accès représente l'autorisation combinée et peut être utilisé pour toute valeur
scope
incluse dans la réponse. - L'autorisation combinée inclut tous les niveaux d'accès que l'utilisateur a accordés au projet d'API, même si les subventions 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 d'un client d'ordinateur de bureau, puis à un autre champ d'application à la même application via un client mobile, l'autorisation combinée incluait les deux champs d'application.
- Si vous révoquez un jeton représentant une autorisation combinée, l'accès à toutes les habilitations de cette autorisation au nom de l'utilisateur associé est révoqué simultanément.
Les exemples de code propres à la langue à l'étape 1: Définir les paramètres d'autorisation et l'exemple d'URL de redirection HTTP/REST sont définis dans l'étape 2 : Rediriger vers le serveur OAuth 2.0 de Google. Tous utilisent l'autorisation incrémentielle. Les exemples de code ci-dessous présentent également le code que vous devez ajouter pour utiliser l'autorisation incrémentielle.
PHP
$client->setIncludeGrantedScopes(true);
Python
Dans Python, définissez l'argument de mot clé include_granted_scopes
sur true
pour vous assurer qu'une requête d'autorisation inclut des niveaux d'accès précédemment accordés. Il est possible que include_granted_scopes
ne soit pas le seul argument du mot clé que vous avez défini, comme indiqué 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
GET https://accounts.google.com/o/oauth2/v2/auth? client_id=your_client_id& response_type=code& state=state_parameter_passthrough_value& scope=https%3A//www.googleapis.com/auth/drive.file& redirect_uri=https%3A//oauth2.example.com/code& prompt=consent& include_granted_scopes=true
Actualiser un jeton d'accès (accès hors connexion)
Les jetons d'accès expirent régulièrement et deviennent des identifiants non valides pour une requête API associée. Vous pouvez actualiser un jeton d'accès sans demander d'autorisation à l'utilisateur (y compris lorsque l'utilisateur n'est pas présent) si vous avez demandé l'accès hors connexion aux champs d'application associés au jeton.
- Si vous utilisez une bibliothèque cliente des API Google, l'objet client actualise le jeton d'accès si nécessaire, à condition de configurer cet objet pour l'accès hors connexion.
- Si vous n'utilisez pas de bibliothèque cliente, vous devez définir le paramètre de requête HTTP
access_type
suroffline
lorsque vous redirigez l'utilisateur vers le serveur OAuth 2.0 de Google. Dans ce cas, le serveur d'autorisation de Google renvoie un jeton d'actualisation lorsque vous échangez un code d'autorisation contre un jeton d'accès. Si le jeton d'accès expire (ou à tout autre moment), vous pouvez l'utiliser pour obtenir un nouveau jeton d'accès.
Toute application devant accéder à une API Google lorsque l'utilisateur n'est pas présent nécessite de demander un accès hors connexion. Par exemple, une application qui exécute des services de sauvegarde ou exécute des actions à des moments prédéterminés doit pouvoir actualiser son jeton d'accès lorsque l'utilisateur n'est pas présent. Le style d'accès par défaut est appelé online
.
Les applications Web côté serveur, les applications installées et les appareils obtiennent tous des jetons d'actualisation pendant le processus d'autorisation. Les jetons d'actualisation ne sont généralement pas utilisés dans les applications Web côté client (JavaScript).
PHP
Si votre application nécessite un accès hors connexion à une API Google, définissez le type d'accès du client API sur offline
:
$client->setAccessType("offline");
Une fois qu'un utilisateur a accordé l'accès hors connexion aux champs d'application demandés, vous pouvez continuer à utiliser le client API pour accéder aux API Google au nom de l'utilisateur, lorsque l'utilisateur est hors connexion. L'objet client actualise le jeton d'accès si nécessaire.
Python
Dans Python, définissez l'argument de mot clé access_type
sur offline
pour vous assurer que vous pouvez actualiser le jeton d'accès sans avoir à envoyer une nouvelle demande d'autorisation à l'utilisateur. Il est possible que access_type
ne soit pas le seul argument du mot clé que vous avez défini, comme indiqué 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é l'accès hors connexion aux champs d'application demandés, vous pouvez continuer à utiliser le client API pour accéder aux API Google au nom de l'utilisateur, lorsque l'utilisateur est hors connexion. L'objet client actualise le jeton d'accès si nécessaire.
Ruby
Si votre application nécessite 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é l'accès hors connexion aux champs d'application demandés, vous pouvez continuer à utiliser le client API pour accéder aux API Google au nom de l'utilisateur, lorsque l'utilisateur est hors connexion. L'objet client actualise le jeton d'accès si nécessaire.
Node.js
Si votre application nécessite 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é l'accès hors connexion aux champs d'application demandés, vous pouvez continuer à utiliser le client API pour accéder aux API Google au nom de l'utilisateur, lorsque l'utilisateur est hors connexion. L'objet client actualise le jeton d'accès si nécessaire.
Les jetons d'accès ont une date d'expiration. 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, vous pouvez utiliser 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 n'a lieu que lors de la première autorisation. 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 recevoir un jeton d'actualisation, vous devez autoriser à nouveau 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, il les acquiert et l'actualise automatiquement lors de l'appel suivant vers l'API.
HTTP/REST
Pour actualiser un jeton d'accès, votre application envoie une requête HTTPS POST
au serveur d'autorisation 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 indiqué 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 du 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. 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 émis sera limité : une limite par combinaison client/utilisateur et une autre par utilisateur pour tous les clients. Nous vous recommandons d'enregistrer les jetons d'actualisation dans un espace de stockage à long terme et de les utiliser tant qu'ils restent valides. Si votre application demande trop de jetons d'actualisation, elle peut atteindre ces limites. Dans ce cas, les anciens jetons d'actualisation ne fonctionnent plus.
Révoquer un jeton
Dans certains cas, l'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 aux sites et aux applications depuis le site et les applications tiers ayant accès à votre compte.
Il est également possible pour une application de révoquer par programmation 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 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 garantir la suppression des autorisations précédemment accordées à l'application.
PHP
Pour révoquer automatiquement un jeton, appelez revokeToken()
:
$client->revokeToken();
Python
Pour révoquer automatiquement un jeton, 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 automatiquement un jeton, 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)
Le 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 est associé à un jeton d'actualisation, le jeton d'actualisation est également révoqué.
Si la révocation a été traitée correctement, 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 automatiquement un jeton, 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 est associé à un jeton d'actualisation, le jeton d'actualisation est également révoqué.
Si la révocation a été traitée correctement, 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 automatiquement un jeton, votre application envoie une requête à https://oauth2.googleapis.com/revoke
et inclut ce 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}
Le 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 est également révoqué.
Si la révocation a été traitée correctement, le code d'état HTTP de la réponse est 200
. En cas d'erreurs, un code d'état HTTP 400
est renvoyé avec un code d'erreur.