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

Utiliser OAuth 2.0 pour les applications de serveur Web

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 d'accès 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 de stocker des fichiers dans leurs Google Drive.

Ce flux OAuth 2.0 est spécifiquement destiné à l'autorisation des utilisateurs. Il est conçu pour les applications qui peuvent 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 l'avoir quittée.

Les applications de serveur Web utilisent également fréquemment des comptes de service pour autoriser les requêtes API, en particulier lorsqu'elles appellent des API Cloud pour accéder à des données basées sur les projets plutôt que sur des données spécifiques à l'utilisateur. Les applications de serveur Web peuvent utiliser des comptes de service conjointement avec l'autorisation des utilisateurs.

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 de votre langage.

Lorsque vous utilisez une bibliothèque cliente des API Google pour gérer le flux OAuth 2.0 de votre application, cette bibliothèque effectue de nombreuses actions que l'application aurait normalement dû gérer seule. Par exemple, il détermine à quel moment l'application peut utiliser ou actualiser les jetons d'accès stockés, ainsi que quand l'application doit de nouveau obtenir le consentement. La bibliothèque cliente génère également des URL de redirection correctes et permet de 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 les activer dans 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.
La liste API Library répertorie toutes les API disponibles, regroupées par famille de produits et par popularité. Si l'API que vous souhaitez activer n'apparaît pas dans la liste, utilisez la recherche pour la trouver 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 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, par exemple http://localhost:8080. Notez que tous les exemples de ce document utilisent http://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 champs d'application 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 auxquels votre application aura besoin d'une autorisation d'accès.

Nous vous recommandons également de demander l'accès aux champs d'application d'autorisation via un processus d'autorisation incrémentielle, au cours duquel 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 qu'elle demande.

Le document Champs d'application des API OAuth 2.0 contient la liste complète des champs d'application que vous pouvez utiliser pour accéder aux API Google.

Exigences en fonction des langues

Pour exécuter l'un des 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 à chaque langage ci-dessous.

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 le consentement d'un utilisateur pour effectuer une requête API en son nom. Votre application doit obtenir cette autorisation 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.
C'est l'utilisateur qui décide d'accorder ou non les autorisations à votre application.
Votre application découvre 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 les 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érerez une URL et définirez ses paramètres.

Les onglets ci-dessous définissent les paramètres d'autorisation pris en charge pour les applications de serveur Web. Les exemples propres au langage montrent é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 identifie votre application à l'aide des informations du fichier client_secret.json. (Consultez la section Créer des identifiants d'autorisation pour en savoir plus sur ce fichier.) L'objet identifie également les champs d'application auxquels votre application demande l'autorisation d'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 de Google. Enfin, le code définit les paramètres facultatifs (access_type et include_granted_scopes).

Par exemple, ce code demande un accès hors connexion en lecture seule au 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" will prompt the user for consent
$client->setPrompt('consent');
$client->setIncludeGrantedScopes(true);   // incremental auth

La requête fournit les informations suivantes:

Paramètres

client_id

Obligatoire

ID client de votre application. Cette valeur se trouve dans API Console Credentials page.

En PHP, appelez la fonction setAuthConfig pour charger les identifiants d'autorisation à partir d'un fichier client_secret.json.

$client = new Google\Client();
$client->setAuthConfig('client_secret.json');

redirect_uri

Obligatoire

Détermine la destination vers laquelle 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é dans le Credentials page API Consolede votre client. Si cette valeur ne correspond pas à un URI de redirection autorisé pour le client_id fourni, une erreur redirect_uri_mismatch est générée.

Notez que le schéma http ou https, la casse et la barre oblique finale ("/") doivent tous correspondre.

Pour définir cette valeur en PHP, appelez la fonction setRedirectUri. Notez que vous devez spécifier un URI de redirection valide pour l'élément client_id fourni.

$client->setRedirectUri('https://oauth2.example.com/code');

scope

Obligatoire

Liste de champs d'application séparé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 champs d'application 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.

Pour définir cette valeur en PHP, appelez la fonction addScope:

$client->addScope(Google\Service\Drive::DRIVE_METADATA_READONLY);

Dans la mesure du possible, nous vous recommandons de demander 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 cet accès.

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ètre valides sont online, qui est la valeur par défaut, et offline.

Définissez la valeur sur offline si votre application doit actualiser les jetons d'accès lorsque l'utilisateur n'est pas présent dans le navigateur. Cette méthode d'actualisation des jetons d'accès est décrite plus loin dans ce document. Cette valeur indique au serveur d'autorisation Google de renvoyer un jeton d'actualisation et un jeton d'accès la première fois que votre application échange un code d'autorisation contre des jetons.

Pour définir cette valeur en PHP, appelez la fonction setAccessType:

$client->setAccessType('offline');

state

Recommandé

Spécifie toute valeur de chaîne utilisée par votre application pour maintenir l'état entre votre requête d'autorisation et la réponse du serveur d'autorisation. Une fois que l'utilisateur a accepté ou refusé la demande d'accès de votre application, le serveur renvoie la valeur exacte que vous envoyez en tant que paire name=value dans le composant de requête d'URL (?) de redirect_uri.

Vous pouvez utiliser ce paramètre à différentes fins, par exemple pour rediriger l'utilisateur vers la bonne ressource dans votre application, envoyer des nonces et limiter la falsification de requête intersite. Étant donné que votre redirect_uri peut être devinée, l'utilisation d'une valeur state peut vous permettre de vous assurer qu'une connexion entrante est le résultat d'une requête d'authentification. Si vous générez une chaîne aléatoire ou encodez le hachage d'un cookie ou d'une autre valeur qui capture l'état du client, vous pouvez valider la réponse pour vous assurer que la requête et la réponse proviennent du même navigateur, ce qui vous protège contre les attaques telles que la falsification de requêtes intersites. Consultez la documentation d'OpenID Connect pour obtenir un exemple de création et de confirmation d'un jeton state.

Pour définir cette valeur en PHP, appelez la fonction setState:

$client->setState($sample_passthrough_value);

include_granted_scopes

Optional

Permet aux applications d'utiliser l'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 true et que la requête d'autorisation est accordée, le nouveau jeton d'accès couvre également tous les champs d'application auxquels l'utilisateur a précédemment accordé l'accès à l'application. Consultez la section sur l'autorisation incrémentielle pour obtenir des exemples.

Pour définir cette valeur en PHP, appelez la fonction setIncludeGrantedScopes:

$client->setIncludeGrantedScopes(true);

enable_granular_consent

Optional

La valeur par défaut est true. Si la valeur est false, des autorisations de compte Google plus précises seront désactivées pour les ID client OAuth créés avant 2019. Aucun effet pour les nouveaux ID client OAuth, car des autorisations plus précises sont toujours activées.

login_hint

Optional

Si votre application sait quel utilisateur tente de s'authentifier, elle peut utiliser ce paramètre pour fournir une indication au serveur d'authentification Google. Le serveur utilise cet 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 sub, qui équivaut à l'ID Google de l'utilisateur.

Pour définir cette valeur en PHP, appelez la fonction setLoginHint:

$client->setLoginHint('None');

prompt

Optional

Liste d'invites sensibles à la casse délimitées par des espaces et destinées à présenter l'utilisateur. Si vous ne spécifiez pas ce paramètre, l'utilisateur n'est invité à y accéder que la première fois que votre projet demande l'accès. Pour en savoir plus, consultez Demander à nouveau le consentement.

Pour définir cette valeur en PHP, appelez la fonction setPrompt:

$client->setPrompt('consent');

Les valeurs possibles sont :

`none`	N'affichez aucun écran d'authentification ou de consentement. Ne doit pas être spécifié avec d'autres valeurs.
`consent`	Demander le consentement de l'utilisateur
`select_account`	Invitez l'utilisateur à sélectionner un compte.

Python

L'extrait de code suivant utilise le module google-auth-oauthlib.flow pour créer 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 auxquels votre application demande l'autorisation d'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 de Google. Enfin, le code définit les paramètres facultatifs (access_type et include_granted_scopes).

Par exemple, ce code demande un accès hors connexion en lecture seule au 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 fournit les informations suivantes:

Paramètres

client_id

Obligatoire

ID client de votre application. Cette valeur se trouve dans API Console Credentials page.

En Python, appelez la méthode from_client_secrets_file pour récupérer l'ID client à partir d'un fichier client_secret.json. (Vous pouvez également utiliser la méthode from_client_config, qui transmet la configuration du client telle qu'elle apparaît à l'origine dans un fichier de codes secrets client, mais n'accède pas au fichier lui-même.)

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

Notez que le schéma http ou https, la casse et la barre oblique finale ("/") doivent tous correspondre.

Pour définir cette valeur en Python, définissez la propriété redirect_uri de l'objet flow:

flow.redirect_uri = 'https://oauth2.example.com/code'

scope

Obligatoire

Liste des champs d'application identifiant 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 champs d'application 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.

En Python, utilisez la même méthode que pour définir client_id afin de spécifier la liste des 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'])

access_type

Recommandé

En Python, définissez le paramètre access_type en spécifiant access_type comme argument de mot clé lors de l'appel de la méthode flow.authorization_url:

authorization_url, state = flow.authorization_url(
    access_type='offline',
    include_granted_scopes='true')

state

Recommandé

En Python, définissez le paramètre state en spécifiant state comme argument de mot clé lors de l'appel de la méthode flow.authorization_url:

authorization_url, state = flow.authorization_url(
    access_type='offline',
    state=sample_passthrough_value,
    include_granted_scopes='true')

include_granted_scopes

Optional

En Python, définissez le paramètre include_granted_scopes en spécifiant include_granted_scopes comme argument de mot clé lors de l'appel de la méthode flow.authorization_url:

authorization_url, state = flow.authorization_url(
    access_type='offline',
    include_granted_scopes='true')

enable_granular_consent

Optional

login_hint

Optional

Définissez la valeur du paramètre sur une adresse e-mail ou un identifiant sub, qui équivaut à l'ID Google de l'utilisateur.

En Python, définissez le paramètre login_hint en spécifiant login_hint comme argument de mot clé lors de l'appel de la méthode flow.authorization_url:

authorization_url, state = flow.authorization_url(
    access_type='offline',
    login_hint='None',
    include_granted_scopes='true')

prompt

Optional

En Python, définissez le paramètre prompt en spécifiant prompt comme argument de mot clé lors de l'appel de la méthode flow.authorization_url:

authorization_url, state = flow.authorization_url(
      access_type='offline',
      prompt='consent',
      include_granted_scopes='true')

Les valeurs possibles sont :

`none`	N'affichez aucun écran d'authentification ou de consentement. Ne doit pas être spécifié avec d'autres valeurs.
`consent`	Demander le consentement de l'utilisateur
`select_account`	Invitez l'utilisateur à sélectionner un compte.

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 demande un accès hors connexion en lecture seule au Google Drive d'un utilisateur:

require 'google/apis/drive_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/drive.metadata.readonly' token_store = Google::Auth::Stores::RedisTokenStore.new(redis: Redis.new) authorizer = Google::Auth::WebUserAuthorizer.new(client_id, scope, token_store, '/oauth2callback')

Your application uses the client object to perform OAuth 2.0 operations, such as generating authorization request URLs and applying access tokens to HTTP requests.

Node.js

The code snippet below creates a google.auth.OAuth2 object, which defines the parameters in the authorization request.

That object uses information from your client_secret.json file to identify your application. To ask for permissions from a user to retrieve an access token, you redirect them to a consent page. To create a consent page URL:

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 : La valeur refresh_token n'est renvoyée que lors de la première autorisation. En savoir plus

HTTP/REST

Le point de terminaison OAuth 2.0 de Google se trouve à 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. Cette valeur se trouve dans API Console Credentials page.

redirect_uri

Obligatoire

Notez que le schéma http ou https, la casse et la barre oblique finale ("/") doivent tous correspondre.

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 code pour les applications de serveur Web.

scope

Obligatoire

Les champs d'application 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.

access_type

Recommandé

state

Recommandé

include_granted_scopes

Optional

enable_granular_consent

Optional

login_hint

Optional

Définissez la valeur du paramètre sur une adresse e-mail ou un identifiant sub, qui équivaut à l'ID Google de l'utilisateur.

prompt

Optional

Les valeurs possibles sont :

`none`	N'affichez aucun écran d'authentification ou de consentement. Ne doit pas être spécifié avec d'autres valeurs.
`consent`	Demander le consentement de l'utilisateur
`select_account`	Invitez l'utilisateur à sélectionner un compte.

Étape 2: Rediriger 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 d'abord accéder à des ressources supplémentaires auxquelles elle n'a pas encore accès.

Le serveur OAuth 2.0 de Google authentifie l'utilisateur et obtient son autorisation pour que votre application accède 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 des services d'API Google auxquels elle demande l'autorisation d'accéder, à l'aide des identifiants d'autorisation de l'utilisateur, ainsi qu'un résumé des champs d'application d'accès à accorder. Celui-ci peut alors 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 adressé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. Vous trouverez ci-dessous la liste des codes d'erreur courants et des solutions suggérées.

`admin_policy_enforced`

Le compte Google ne peut pas autoriser un ou plusieurs des 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 savoir comment un administrateur peut restreindre l'accès à tous les champs d'application ou à des champs d'application sensibles et restreints tant que l'accès n'a pas été explicitement accordé à votre ID client OAuth.

`disallowed_useragent`

Le point de terminaison de l'autorisation est affiché 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. Nous recommandons aux développeurs d'utiliser plutôt 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 depuis votre site. Les développeurs doivent autoriser les liens généraux à s'ouvrir 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 d'onglets personnalisés Android est également une option compatible.

iOS

Les développeurs iOS et macOS peuvent rencontrer cette erreur lorsqu'ils ouvrent des requêtes d'autorisation dans WKWebView. Nous recommandons aux développeurs d'utiliser plutôt 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 depuis votre site. Les développeurs doivent autoriser les liens généraux à s'ouvrir 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 d'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 votre écran de consentement OAuth".

`invalid_client`

Le code secret du client OAuth est incorrect. Vérifiez 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'autorisation incrémentielle, il est possible que le jeton ait expiré ou qu'il ait été invalidé. Authentifiez à nouveau l'utilisateur et demandez-lui son consentement pour obtenir de nouveaux jetons. Si l'erreur persiste, assurez-vous 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`

Le redirect_uri transmis dans la requête d'autorisation ne correspond à aucun URI de redirection autorisé pour l'ID client OAuth. Examinez les URI de redirection autorisés dans le 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 accepté. 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'a pas été correct.
Il manque des paramètres obligatoires dans la requête
La requête utilise une méthode d'autorisation non compatible avec Google. Vérifier 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 requête 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:

Une réponse d'erreur:

https://oauth2.example.com/auth?error=access_denied

Réponse avec un code d'autorisation:

https://oauth2.example.com/auth?code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7

Important:Si le point de terminaison de votre réponse affiche une page HTML, toutes les ressources de cette page pourront voir le code d'autorisation dans l'URL. Les scripts peuvent lire l'URL directement, et celle qui figure dans l'en-tête HTTP Referer peut être envoyée à tout ou partie des ressources de la page.

Déterminez attentivement si vous souhaitez envoyer des identifiants d'autorisation à toutes les ressources de cette page (en particulier les scripts tiers tels que les plug-ins de réseaux sociaux et les analyses). Pour éviter ce problème, nous recommandons que le serveur traite d'abord la requête, puis redirige vers une autre URL qui n'inclut pas les paramètres de réponse.

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

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/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

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 les utilisateurs vers l'URL qui a initialement demandé l'autorisation. Cette action 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.
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 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 fichier API Console Credentials 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

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 avez défini le paramètre `access_type` sur `offline` dans la requête initiale adressée au serveur d'autorisation de Google.
`scope`	Champs d'application 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 affiché. 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/drive.metadata.readonly",
  "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. Vous trouverez ci-dessous la liste des codes d'erreur courants et des solutions suggérées.

`invalid_grant`

Le code d'autorisation fourni n'est pas valide ou son format est incorrect. Demandez un nouveau code en redémarrant le processus OAuth afin de demander à nouveau le consentement de l'utilisateur.

Appeler les 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éthode setAccessToken :
```
$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 :
```
$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 le Google Drive de l'utilisateur authentifié :
```
$files = $drive->files->listFiles(array())->getItems();
```

Python

Après avoir 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 propres à 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èque googleapiclient.discovery avec le nom et la version de l'API, ainsi que les identifiants utilisateur. Par exemple, pour appeler la version 3 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 le Google Drive de l'utilisateur authentifié :
```
files = drive.files().list().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 propres à 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 Drive :
```
drive = Google::Apis::DriveV3::DriveService.new
```
Définissez les identifiants sur le service :
```
drive.authorization = 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 le Google Drive de l'utilisateur authentifié :
```
files = drive.list_files
```

Vous pouvez également fournir une autorisation pour chaque méthode en fournissant le paramètre options à une méthode:

files = drive.list_files(options: { authorization: credentials })

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 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é, à condition que le ou les champs d'application requis par l'API aient é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 Bearer de l'en-tête HTTP Authorization. Dans la mesure du possible, il est préférable d'utiliser l'en-tête HTTP, 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 Drive Files).

Vous pouvez essayer toutes les API Google et consulter leur champ d'application sur OAuth 2.0 Playground.

Exemples HTTP GET

Un appel au point de terminaison drive.files (l'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 (recommandée):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

Vous pouvez également utiliser l'option de 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 imprime une liste de fichiers au format JSON dans le Google Drive d'un utilisateur une fois que celui-ci s'est authentifié et a autorisé l'application à accéder à ses métadonnées Drive.

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 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 et oauth2callback.php avec le contenu ci-dessous.
Exécutez l'exemple avec un serveur Web configuré pour diffuser du contenu 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\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 à 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 le flux d'authentification directement:ce lien redirige vers une page qui tente de rediriger l'utilisateur via 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 la session Flask:ce lien efface les identifiants d'autorisation stockés dans la session Flask. Vous pouvez ainsi voir ce qui se passerait si un utilisateur ayant déjà accordé l'autorisation à 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é des autorisations accordées à votre application et que votre application tentait toujours d'autoriser une requête avec un jeton d'accès révoqué.

Remarque:Pour exécuter ce code localement, vous devez avoir suivi les instructions de la section Conditions préalables. Vous devez notamment avoir défini http://localhost:8080 comme URI de redirection valide pour vos identifiants et téléchargé le fichier client_secret.json correspondant à ces identifiants dans votre répertoire de travail.

# -*- 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_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
  drive = Google::Apis::DriveV3::DriveService.new
  files = drive.list_files(options: { authorization: credentials })
  "<pre>#{JSON.pretty_generate(files.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 API Console, ajoutez l'URL de la machine locale à la liste des URL de redirection. Par exemple, ajoutez http://localhost.
Assurez-vous d'avoir installé une version LTS de maintenance, une version LTS active ou la version actuelle de Node.js.

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');

/**
 * 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. Pour ce flux, nous vous recommandons d'utiliser la bibliothèque cliente des API Google pour Python. (L'exemple dans 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 d'aider les développeurs à sécuriser leurs applications. Vos URI de redirection doivent respecter ces règles. Reportez-vous à la section 3 du document 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 le 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 de l'hôte local sont exemptées de cette règle.
Domaine	Les domaines de premier niveau de l'hôte (domaines de premier niveau) doivent appartenir à la liste des suffixes publics. Les domaines hôtes ne peuvent pas être `“googleusercontent.com”`. Les URI de redirection ne peuvent pas contenir de domaines de raccourcissement d'URL (par exemple, `goo.gl`), sauf si l'application est propriétaire du domaine. De plus, si une application qui possède un domaine raccourci choisit de rediriger vers ce domaine, cet URI de redirection doit contenir `“/google-callback/”` dans son chemin ou se terminer par `“/google-callback”`.
Informations 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 de répertoire), qui est représentée par un élément `“/..”` ou `“\..”`, ou par leur encodage d'URL.
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 : Caractères génériques (`'*'`) Caractères ASCII non imprimables Encodages de pourcentage incorrects (tout encodage de pourcentage qui ne respecte pas la forme d'encodage d'URL d'un signe de pourcentage suivi de deux chiffres hexadécimaux) Les caractères NULL (un caractère NULL encodé, par exemple, `%00`, `%C0%80`)

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. Pour optimiser l'expérience utilisateur, il est recommandé de demander l'autorisation d'accéder à des ressources au moment où vous en avez besoin. Pour permettre cette pratique, le serveur d'autorisation de Google accepte l'autorisation incrémentielle. Cette fonctionnalité vous permet de demander les niveaux d'accès selon les 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, une application qui permet aux utilisateurs de sampler des titres musicaux et de créer des mix peut nécessiter très peu de ressources au moment de la connexion, peut-être rien d'autre que le nom de la personne qui se connecte. Toutefois, pour enregistrer un mixage finalisé, vous devrez accéder à leur Google Drive. Il serait naturel pour la plupart des utilisateurs de n'être invités à accéder à leur Google Drive qu'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 ultérieurement le champ d'application https://www.googleapis.com/auth/drive.file au moment de la première requête pour enregistrer un mélange.

Pour mettre en œuvre une autorisation incrémentielle, suivez la procédure normale pour demander un jeton d'accès, mais assurez-vous que la demande d'autorisation inclut les 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, ce jeton représente l'autorisation combinée et peut être utilisé pour toutes les valeurs scope incluses 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 par 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 en a accordé un autre à la même application via un client mobile, l'autorisation combinée inclut les deux champs d'application.
Si vous révoquez un jeton qui représente une autorisation combinée, l'accès à tous les champs d'application de cette autorisation pour le compte de l'utilisateur associé est simultanément révoqué.

Les exemples de code propre à chaque langage à 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 indiquent également le code que vous devez ajouter pour utiliser l'autorisation incrémentielle.

Actualiser un jeton d'accès (accès hors connexion)

Les jetons d'accès expirent régulièrement et deviennent non valides pour une requête API associée. Vous pouvez actualiser un jeton d'accès sans demander l'autorisation de l'utilisateur (y compris en son absence) si vous avez demandé un 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 tant que vous le configurez pour un 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 sur offline 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. Ensuite, si le jeton d'accès expire (ou à un autre moment), vous pouvez utiliser un jeton d'actualisation pour obtenir un nouveau jeton d'accès.

La demande d'accès hors connexion est obligatoire pour toute application qui doit accéder à une API Google en l'absence de l'utilisateur. Par exemple, une application qui effectue des services de sauvegarde ou exécute des actions à des heures prédéterminées doit pouvoir actualiser son jeton d'accès en l'absence de l'utilisateur. Le style d'accès par défaut est 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 a besoin d'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é un accès hors connexion aux champs d'application demandés, vous pouvez continuer à utiliser le client API pour accéder aux API Google en son nom lorsque celui-ci est hors connexion. L'objet client actualisera 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 de l'utilisateur. Il est très 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')

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"}
)

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
});

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, 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 jeton ne se produit que lors de la première autorisation. Vous devez avoir défini 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 devrez autoriser à nouveau l'application à 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 acquis 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 montre 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). Vous devez enregistrer les jetons d'actualisation dans un espace de stockage à long terme et continuer à les utiliser tant qu'ils restent valides. Si votre application demande trop de jetons d'actualisation, elle peut atteindre 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. L'utilisateur peut révoquer l'accès en accédant aux paramètres du compte. Pour en savoir plus, consultez la section Supprimer l'accès à un site ou une application de la page "Applications et sites tiers ayant accès à votre compte" pour en savoir plus.

Une application peut également révoquer l'accès qui lui est accordé par programmation. La révocation programmatique est importante lorsqu'un utilisateur se désabonne ou supprime une application, ou lorsqu'elle a modifié les ressources d'API requises par une application. 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 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 en incluant le jeton en tant que paramètre et en définissant 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 programmatique, 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. S'il s'agit d'un jeton d'accès associé à un jeton d'actualisation correspondant, le jeton d'actualisation est également révoqué.

Si la révocation est 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 un jeton de manière programmatique, 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. S'il s'agit d'un jeton d'accès associé à un jeton d'actualisation correspondant, le jeton d'actualisation est également révoqué.

Si la révocation est 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 un jeton de manière programmatique, 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 est associé à un jeton d'actualisation, le jeton d'actualisation est également révoqué.

Si la révocation est traitée correctement, le code d'état HTTP de la réponse est 200. En cas d'erreur, un code d'état HTTP 400 est renvoyé avec un code d'erreur.

Utiliser OAuth 2.0 pour les applications de serveur Web

Bibliothèques clientes

Conditions préalables

Activer les API pour votre projet.

Créer des identifiants d'autorisation

Identifier les niveaux d'accès

Exigences en fonction des langues

PHP

Python

Ruby

Node.js

HTTP/REST

Obtenir des jetons d'accès OAuth 2.0

Étape 1: Définissez les paramètres d'autorisation

PHP

Python

Ruby

Node.js

HTTP/REST

Étape 2: Rediriger vers le serveur OAuth 2.0 de Google

PHP

Python

Ruby

Node.js

HTTP/REST

Sample redirect to Google's authorization server

Étape 3: Google invite l'utilisateur à donner son consentement

Erreurs

admin_policy_enforced

disallowed_useragent

Android

iOS

org_internal

invalid_client

invalid_grant

redirect_uri_mismatch

invalid_request

Étape 4: Gérer la réponse du serveur OAuth 2.0

Exemple de réponse du serveur OAuth 2.0

Étape 5: Échangez le code d'autorisation contre des jetons d'actualisation et d'accès

PHP

Python

Ruby

Node.js

HTTP/REST

Erreurs

invalid_grant

Appeler les API Google

PHP

Python

Ruby

Node.js

HTTP/REST

Exemples HTTP GET

Exemples curl

Exemple complet

PHP

index.php

oauth2callback.php

Python

Ruby

Node.js

main.js

HTTP/REST

Règles de validation de l'URI de redirection

Autorisation incrémentielle

PHP

Python

Ruby

Node.js

HTTP/REST

Actualiser un jeton d'accès (accès hors connexion)

PHP

Python

Ruby

Node.js

HTTP/REST

Révoquer un jeton

PHP

Python

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`invalid_client`

`invalid_grant`

`redirect_uri_mismatch`

`invalid_request`

`invalid_grant`

Exemples `curl`