Utiliser OAuth 2.0 pour les applications de serveur Web

Ce document explique comment les applications de serveur Web utilisent les bibliothèques clientes pour les API Google ou Points de terminaison OAuth 2.0 pour implémenter l'autorisation d'accès OAuth 2.0 aux API Google.

OAuth 2.0 permet aux utilisateurs de partager des données spécifiques avec une application tout en conservant leur nom d'utilisateur, leur mot de passe et toute autre information privée. Par exemple, une application peut utiliser OAuth 2.0 pour obtenir l'autorisation aux utilisateurs de stocker des fichiers dans leurs Google Drive.

Ce flux OAuth 2.0 est spécifiquement destiné à l'autorisation de l'utilisateur. Il est conçu pour les applications capable de stocker des informations confidentielles et de maintenir l'état. Un serveur Web correctement autorisé application peut accéder à une API pendant que l'utilisateur interagit avec l'application ou après que l'utilisateur a quitté l'application.

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

Bibliothèques clientes

Les exemples spécifiques à un langage figurant sur cette page utilisent les bibliothèques clientes des API Google à implémenter Autorisation OAuth 2.0. Pour exécuter les exemples de code, vous devez d'abord installer bibliothèque cliente pour votre langage.

Lorsque vous utilisez une bibliothèque cliente des API Google pour gérer le flux OAuth 2.0 de votre application, le client effectue de nombreuses actions que l'application devrait normalement gérer elle-même. Pour par exemple, il détermine à quel moment l'application peut utiliser ou actualiser les jetons d'accès stockés, lorsque l'application doit de nouveau obtenir le consentement. De plus, la bibliothèque cliente génère URL et aide à implémenter 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:

Prérequis

Activer les API pour votre projet.

Toute application qui appelle des API Google doit activer ces API dans le API Console

Pour activer une API pour votre projet:

  1. Open the API Library dans la Google API Console
  2. If prompted, select a project, or create a new one.
  3. API Library liste toutes les API disponibles, regroupées par produit. la famille et leur popularité. Si l'API que vous souhaitez activer n'apparaît pas dans la liste, utilisez la recherche pour recherchez-le ou cliquez sur Tout afficher dans la famille de produits à laquelle il appartient.
  4. Sélectionnez l'API que vous souhaitez activer, puis cliquez sur le bouton Activer.
  5. If prompted, enable billing.
  6. 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 auprès du serveur OAuth 2.0 de Google. Les étapes suivantes expliquent comment créer des identifiants pour votre projet. Vos applications peuvent ensuite utiliser les identifiants pour accéder aux API que vous avez activées pour ce projet.

  1. Go to the Credentials page.
  2. Cliquez sur Créer des identifiants > ID client OAuth.
  3. Sélectionnez le type d'application Application Web.
  4. Remplissez le formulaire, puis cliquez sur Créer. Les applications qui utilisent des langages et des frameworks comme PHP, Java, Python, Ruby et .NET doivent spécifier des URI de redirection autorisés. La les URI de redirection sont les points de terminaison auxquels le serveur OAuth 2.0 peut envoyer des réponses. Ces points de terminaison doivent respecter les règles de validation de Google.

    Pour les tests, vous pouvez spécifier des URI qui font référence à la machine locale, tels que http://localhost:8080 Gardez cela à l'esprit, 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 votre application n'expose pas les codes d'autorisation à d'autres ressources du .

Après avoir créé vos identifiants, téléchargez le fichier client_secret.json à partir de API ConsoleStockez le fichier de façon sécurisée dans un emplacement qui ne auquel votre application peut accéder.

Identifier les niveaux d'accès

Les niveaux d'accès permettent à votre application de ne demander l'accès qu'aux ressources dont elle a besoin, tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils accordent à votre application. Il existe donc peut représenter une relation inverse entre le nombre de champs d'application demandés et la probabilité l'obtention du consentement de l'utilisateur.

Avant de commencer à implémenter l'autorisation OAuth 2.0, nous vous recommandons d'identifier les champs d'application auxquelles votre application a besoin d'une autorisation d'accès.

Nous recommandons également que votre application demande l'accès aux niveaux d'autorisation via une d'autorisation incrémentielle, dans lequel votre application demande l'accès aux données de l'utilisateur en contexte. Cette bonne pratique aide les utilisateurs à mieux comprendre pourquoi votre application a besoin de l'accès qu'elle demande.

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 propres à la langue

Pour exécuter l'un des exemples de code présentés dans ce document, vous devez disposer d'un compte Google, d'un accès au Internet et un navigateur Web. Si vous utilisez l'une des bibliothèques clientes de l'API, consultez également des exigences spécifiques à chaque langue ci-dessous.

PHP

Pour exécuter les exemples de code PHP de ce document, vous avez besoin des éléments suivants:

  • PHP 5.6 ou version ultérieure, avec l'interface de ligne de commande (CLI) et l'extension JSON installées
  • L'outil de gestion des dépendances Composer
  • Bibliothèque cliente des API Google pour PHP:

    composer require google/apiclient:^2.10

Python

Pour exécuter les exemples de code Python présentés dans ce document, vous avez besoin des éléments suivants:

  • Python 2.6 ou version ultérieure
  • L'outil de gestion de packages pip
  • Bibliothèque cliente des API Google pour Python:
    pip install --upgrade google-api-python-client
  • google-auth, google-auth-oauthlib et google-auth-httplib2 pour l'autorisation de l'utilisateur
    pip install --upgrade google-auth google-auth-oauthlib google-auth-httplib2
  • Framework d'applications Web Python Flask.
    pip install --upgrade flask
  • Bibliothèque HTTP requests.
    pip install --upgrade requests

Ruby

Pour exécuter les exemples de code Ruby présentés dans ce document, vous avez besoin des éléments suivants:

  • Ruby 2.6 ou version ultérieure
  • La bibliothèque Google Auth pour Ruby:

    gem install googleauth
  • Framework d'applications Web Sinatra Ruby.

    gem install sinatra

Node.js

Pour exécuter les exemples de code Node.js présentés dans ce document, vous avez besoin des éléments suivants:

  • La version LTS de maintenance, la version LTS active ou la version actuelle de Node.js.
  • Le client Node.js des API Google:

    npm install googleapis crypto express express-session

HTTP/REST

Il n'est pas nécessaire d'installer des bibliothèques pour pouvoir appeler directement le protocole les points de terminaison.

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 pour obtenir le consentement d'un utilisateur pour envoyer une requête API au nom de l'utilisateur. Votre application doit inclure avant de 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:

  1. Votre application identifie les autorisations dont elle a besoin.
  2. Votre application redirige l'utilisateur vers Google avec la liste des autorisations.
  3. L'utilisateur décide d'accorder ou non les autorisations à votre application.
  4. Votre application détermine ce que l'utilisateur a décidé.
  5. 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 demande définit des paramètres identifier votre application et définir 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, 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érez une URL et définissez le paramètre paramètres de cette URL.

Les onglets ci-dessous définissent les paramètres d'autorisation pris en charge pour les applications de serveur Web. La des exemples propres au langage montrent également comment utiliser une bibliothèque cliente ou une bibliothèque d'autorisation pour configurer un objet qui définit ces paramètres.

PHP

L'extrait de code ci-dessous crée un objet Google\Client(), qui définit le dans la requête d'autorisation.

Cet objet utilise les informations de votre fichier client_secret.json pour identifier votre application. Consultez la section Créer des identifiants d'autorisation pour en savoir plus ce fichier.) L'objet identifie également les champs d'application pour lesquels votre application demande l'autorisation. et l'URL du point de terminaison d'authentification de votre application, qui gérera la réponse le serveur OAuth 2.0 de Google. Enfin, le code définit les options facultatives access_type et Paramètres include_granted_scopes.

Par exemple, ce code demande un accès hors connexion en lecture seule aux données Google Drive:

$client = new Google\Client();

// Required, call the setAuthConfig function to load authorization credentials from
// client_secret.json file.
$client->setAuthConfig('client_secret.json');

// Required, to set the scope value, call the addScope function
$client->addScope(Google\Service\Drive::DRIVE_METADATA_READONLY);

// Required, call the setRedirectUri function to specify a valid redirect URI for the
// provided client_id
$client->setRedirectUri('http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php');

// Recommended, offline access will give you both an access and refresh token so that
// your app can refresh the access token without user interaction.
$client->setAccessType('offline');

// Recommended, call the setState function. Using a state value can increase your assurance that
// an incoming connection is the result of an authentication request.
$client->setState($sample_passthrough_value);

// Optional, if your application knows which user is trying to authenticate, it can use this
// parameter to provide a hint to the Google Authentication Server.
$client->setLoginHint('hint@example.com');

// Optional, call the setPrompt function to set "consent" will prompt the user for consent
$client->setPrompt('consent');

// Optional, call the setIncludeGrantedScopes function with true to enable incremental
// authorization
$client->setIncludeGrantedScopes(true);

Python

L'extrait de code suivant utilise le module google-auth-oauthlib.flow pour construire la demande d'autorisation.

Le code construit un objet Flow, qui identifie votre application à l'aide de les informations du fichier client_secret.json que vous avez téléchargé après créer 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 de l'API d'authentification unique, 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 aux données Google Drive:

import google.oauth2.credentials
import google_auth_oauthlib.flow

# Required, call the from_client_secrets_file method to retrieve the client ID from a
# client_secret.json file. The client ID (from that file) and access scopes are required. (You can
# also use the from_client_config method, which passes the client configuration as it originally
# appeared in a client secrets file but doesn't access the file itself.)
flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
    'client_secret.json',
    scopes=['https://www.googleapis.com/auth/drive.metadata.readonly'])

# Required, indicate where the API server will redirect the user after the user completes
# the authorization flow. The redirect URI is required. The value must exactly
# match one of the authorized redirect URIs for the OAuth 2.0 client, which you
# configured in the API Console. If this value doesn't match an authorized URI,
# you will get a 'redirect_uri_mismatch' error.
flow.redirect_uri = 'https://www.example.com/oauth2callback'

# Generate URL for request to Google's OAuth 2.0 server.
# Use kwargs to set optional request parameters.
authorization_url, state = flow.authorization_url(
    # Recommended, enable offline access so that you can refresh an access token without
    # re-prompting the user for permission. Recommended for web server apps.
    access_type='offline',
    # Optional, enable incremental authorization. Recommended as a best practice.
    include_granted_scopes='true',
    # Optional, if your application knows which user is trying to authenticate, it can use this
    # parameter to provide a hint to the Google Authentication Server.
    login_hint='hint@example.com',
    # Optional, set prompt to 'consent' will prompt the user for consent
    prompt='consent')

Ruby

Utilisez le fichier client_secrets.json que vous avez créé pour configurer un objet client dans votre application. Lorsque vous configurez un objet client, vous spécifiez les niveaux d'accès dont votre application a besoin ainsi que l'URL du point de terminaison d'authentification de votre application, qui gérera la réponse à partir du serveur OAuth 2.0.

Par exemple, ce code demande un accès hors connexion en lecture seule aux données Google Drive:

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

Votre application utilise l'objet client pour effectuer des opérations OAuth 2.0, telles que la génération les URL de requête d'autorisation et l'application de jetons d'accès aux requêtes HTTP.

Node.js

L'extrait de code suivant crée un objet google.auth.OAuth2, qui définit le dans la requête d'autorisation.

Cet objet identifie votre application à l'aide des informations de votre fichier client_secret.json. À demander l'autorisation d'un utilisateur pour récupérer un jeton d'accès, vous le redirigez vers une page de consentement. Pour créer une URL de page de consentement:

const {google} = require('googleapis');
const crypto = require('crypto');
const express = require('express');
const session = require('express-session');

/**
 * To use OAuth2 authentication, we need access to a CLIENT_ID, CLIENT_SECRET, AND REDIRECT_URI
 * from the client_secret.json file. To get these credentials for your application, visit
 * https://console.cloud.google.com/apis/credentials.
 */
const oauth2Client = new google.auth.OAuth2(
  YOUR_CLIENT_ID,
  YOUR_CLIENT_SECRET,
  YOUR_REDIRECT_URL
);

// Access scopes for read-only Drive activity.
const scopes = [
  'https://www.googleapis.com/auth/drive.metadata.readonly'
];

// Generate a secure random state value.
const state = crypto.randomBytes(32).toString('hex');

// Store state in the session
req.session.state = state;

// Generate a url that asks permissions for the Drive activity scope
const authorizationUrl = oauth2Client.generateAuthUrl({
  // 'online' (default) or 'offline' (gets refresh_token)
  access_type: 'offline',
  /** Pass in the scopes array defined above.
    * Alternatively, if only one scope is needed, you can pass a scope URL as a string */
  scope: scopes,
  // Enable incremental authorization. Recommended as a best practice.
  include_granted_scopes: true,
  // Include the state parameter to reduce the risk of CSRF attacks.
  state: state
});

Remarque importante : La valeur refresh_token n'est renvoyée que lors de la première une autorisation. Plus d'infos en cliquant ici.

HTTP/REST

Le point de terminaison OAuth 2.0 de Google est à https://accounts.google.com/o/oauth2/v2/auth. Ce n'est accessible que via HTTPS. Les connexions HTTP ordinaires sont refusées.

Le serveur d'autorisation de Google accepte les paramètres de chaîne de requête suivants pour le Web applications de serveur:

Paramètres
client_id Obligatoire

ID client de votre application. Vous trouverez cette valeur dans le API Console Credentials page

redirect_uri Obligatoire

Détermine où le serveur d'API redirige l'utilisateur une fois que celui-ci a effectué la 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 API Console Credentials pageSi cette valeur ne correspond pas à URI de redirection autorisé pour l'élément client_id fourni, vous obtiendrez une Erreur redirect_uri_mismatch.

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

A délimité par des espaces des champs d'application qui identifient les ressources auxquelles votre application pourrait accéder au nom de l'utilisateur. Ces valeurs déterminent l'écran de consentement que Google présente aux utilisateurs utilisateur.

Les niveaux d'accès permettent à votre application de ne demander l'accès qu'aux ressources dont elle a besoin tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils accordent 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.

Nous recommandons que votre application demande l'accès aux champs d'application des autorisations en contexte dès que possible. En demandant l'accès aux données utilisateur en contexte, via l'autorisation incrémentielle, vous aidez les utilisateurs à comprendre pourquoi votre application a besoin de l'accès qu'elle demande.

access_type Recommandé

Indique si votre application peut actualiser les jetons d'accès en l'absence de l'utilisateur dans le navigateur. Les valeurs de paramètre valides sont online (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 permet d'actualiser l'accès de jetons décrits plus loin dans ce document. Cette valeur indique à Google les autorisations serveur de renvoyer un jeton d'actualisation et un jeton d'accès la première fois que votre échange un code d'autorisation contre des jetons.

state Recommandé

Spécifie toute valeur de chaîne utilisée par votre application pour maintenir l'état entre vos la 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 name=value dans le paramètre Composant de requête d'URL (?) de redirect_uri après que l'utilisateur a donné son accord ou refusé demande d'accès.

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

include_granted_scopes Optional

Permet aux applications d'utiliser une autorisation incrémentielle pour demander l'accès à des les niveaux d'accès en contexte. Si vous définissez la valeur de ce paramètre sur true et que demande d'autorisation donnée, le nouveau jeton d'accès couvrira également les champs d'application auquel l'utilisateur a précédemment accordé l'accès à l'application. Consultez le autorisation incrémentielle pour obtenir des exemples.

login_hint Optional

Si votre application sait quel utilisateur tente de s'authentifier, elle peut utiliser ce paramètre pour fournir un indice au serveur d'authentification Google. Le serveur utilise l'indice pour simplifier le processus de connexion soit en préremplissant le champ de l'adresse e-mail dans le formulaire de connexion, soit en en sélectionnant la session multiconnexion appropriée.

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

prompt Optional

Liste de requêtes sensibles à la casse et séparées par des espaces à présenter à l'utilisateur. Si vous ne spécifiez ce paramètre, l'utilisateur n'est invité à le faire que la première fois que votre projet demande l'accès. Voir <ph type="x-smartling-placeholder"></ph> Demander un nouveau consentement pour en savoir plus.

Les valeurs possibles sont :

none N'affichez pas d'é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: Redirection vers le serveur OAuth 2.0 de Google

Redirigez l'utilisateur vers le serveur OAuth 2.0 de Google pour lancer l'authentification et d'autorisation. En général, cela se produit lorsque votre application doit accéder pour la première fois les données de l'utilisateur. Dans le cas d'une autorisation incrémentielle, a lieu également lorsque votre application doit accéder pour la première fois à des ressources supplémentaires n'ont pas encore l'autorisation d'accès.

PHP

  1. Générez une URL pour demander l'accès au serveur OAuth 2.0 de Google:
    $auth_url = $client->createAuthUrl();
  2. Redirigez 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 de l'application Web Flask. framework d'application:

return flask.redirect(authorization_url)

Ruby

  1. Générez une URL pour demander l'accès au serveur OAuth 2.0 de Google:
    auth_uri = authorizer.get_authorization_url(login_hint: user_id, request: request)
  2. Redirigez l'utilisateur vers auth_uri.

Node.js

  1. Utilisez l'URL authorizationUrl générée à l'étape 1. generateAuthUrl pour demander l'accès au serveur OAuth 2.0 de Google.
  2. Redirigez l'utilisateur vers authorizationUrl.
    res.redirect(authorizationUrl);

HTTP/REST

Sample redirect to Google's authorization server

An example URL is shown below, with line breaks and spaces for readability.

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 l'URL de requête créée, redirigez l'utilisateur vers celle-ci.

Le serveur OAuth 2.0 de Google authentifie l'utilisateur et obtient son consentement pour vos pour accéder aux champs d'application demandés. La réponse est renvoyée à votre application. à l'aide de l'URL de redirection que vous avez spécifiée.

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

Au cours de cette étape, l'utilisateur décide d'accorder ou non l'accès demandé à votre application. À cette adresse étape, Google affiche une fenêtre de consentement indiquant le nom de votre application et l'API Google services auxquels il demande l'autorisation d'accéder avec les informations d'identification de l'utilisateur et un résumé des niveaux d'accès à accorder. La l'utilisateur peut alors consentir à accorder l'accès à un ou plusieurs champs d'application demandés par votre application ou refuser la demande.

Votre application n'a rien à faire à ce stade, car elle attend la réponse de Serveur OAuth 2.0 de Google indiquant si un accès a été accordé Cette réponse est expliquée dans l'étape suivante.

Erreurs

Les requêtes envoyées au point de terminaison d'autorisation OAuth 2.0 de Google peuvent afficher des messages d'erreur destinés aux utilisateurs au lieu des flux d'authentification et d'autorisation attendus. Codes d'erreur courants et suggestions résolutions sont indiquées ci-dessous.

admin_policy_enforced

Le compte Google ne peut pas autoriser un ou plusieurs champs d'application demandés en raison des règles de leur administrateur Google Workspace. Consultez l'article d'aide Administrateur Google Workspace Contrôlez les enregistrements les applications internes accèdent aux données Google Workspace pour en savoir plus sur la façon dont un administrateur peut restreindre l'accès à tous les niveaux d'accès ou des niveaux d'accès restreints jusqu'à ce que l'accès soit 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 le Règles OAuth 2.0

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 plutôt utiliser des bibliothèques Android telles que Google Sign-In pour Android ou OpenID Foundation 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 un utilisateur accède au point de terminaison d'autorisation OAuth 2.0 de Google depuis sur votre site. Les développeurs doivent autoriser l'ouverture de liens généraux dans le gestionnaire de liens par défaut du système d'exploitation, qui inclut à la fois Android App Links ou l'application de navigateur par défaut. La Onglets personnalisés Android bibliothèque est également une option prise en charge.

iOS

Les développeurs iOS et macOS peuvent rencontrer cette erreur lorsqu'ils ouvrent des demandes d'autorisation dans WKWebView Les développeurs doivent plutôt utiliser des bibliothèques iOS telles que Google Sign-In pour iOS ou OpenID Foundation 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 un utilisateur accède au point de terminaison d'autorisation OAuth 2.0 de Google sur votre site. Les développeurs doivent autoriser l'ouverture de liens généraux dans le gestionnaire de liens par défaut du système d'exploitation, qui inclut à la fois Liens universels ou l'application de navigateur par défaut. La SFSafariViewController bibliothèque est également une option prise en charge.

org_internal

L'ID client OAuth de la requête fait partie d'un projet limitant l'accès aux comptes Google dans un spécifiques Organisation Google Cloud. Pour en savoir plus sur cette option de configuration, consultez la Type d'utilisateur de l'article d'aide "Configurer l'écran de consentement OAuth".

invalid_client

Le code secret du client OAuth est incorrect. Consultez les Client OAuth configuration, y compris l'ID client et le code secret utilisés pour cette requête.

invalid_grant

Lors de l'actualisation d'un jeton d'accès ou de l'utilisation autorisation incrémentielle, le jeton a peut-être expiré ou a a été invalidée. Authentifiez à nouveau l'utilisateur et demandez son consentement pour obtenir de nouveaux jetons. Si vous poursuivez pour que ce message d'erreur s'affiche, vérifiez que votre application est correctement configurée et que vous n'avez pas en utilisant les jetons et les paramètres appropriés dans votre requête. Sinon, le compte utilisateur peut avoir ont été supprimées ou désactivées.

redirect_uri_mismatch

L'élément redirect_uri transmis dans la demande d'autorisation ne correspond à aucune URI de redirection pour l'ID client OAuth. Examinez les URI de redirection autorisés dans le fichier Google API Console Credentials page

Le paramètre redirect_uri peut faire référence au flux OAuth hors bande (OOB) qui a est obsolète et n'est plus compatible. Consultez le guide de migration pour mettre à jour votre l'intégration.

invalid_request

Un problème est survenu avec votre demande. Plusieurs raisons peuvent expliquer ce problème:

  • Le format de la requête n'est pas correct.
  • Il manquait des paramètres obligatoires dans la requête
  • La requête utilise une méthode d'autorisation non compatible avec Google. Valider votre protocole OAuth utilise une méthode d'intégration recommandée

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

Le serveur OAuth 2.0 répond à la demande d'accès de votre application en utilisant l'URL spécifiée. dans la demande.

Si l'utilisateur approuve la demande d'accès, la réponse contient un code d'autorisation. Si l'utilisateur n'approuve pas la demande, la réponse contient un message d'erreur. La code d'autorisation ou message d'erreur renvoyé au serveur Web apparaît sur la requête comme indiqué ci-dessous:

Réponse d'erreur:

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

Réponse avec code d'autorisation:

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

Exemple de réponse du serveur OAuth 2.0

Vous pouvez tester ce flux en cliquant sur l'URL d'exemple suivante, qui demande accès en lecture seule pour afficher les métadonnées des fichiers de votre Google Drive:

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A//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, qui générera probablement 404 NOT FOUND, sauf si votre ordinateur local diffuse un fichier à cette adresse. La L'étape suivante fournit plus de détails sur les informations renvoyées dans l'URI lorsque l'utilisateur redirigé vers votre application.

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

Une fois que le serveur Web a reçu le code d'autorisation, il peut l'échanger. un jeton d'accès.

PHP

Pour échanger un code d'autorisation contre un jeton d'accès, utilisez authenticate méthode:

$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, vérifiez l'autorisation à l'aide de la bibliothèque google-auth la réponse du serveur. Utilisez ensuite la méthode flow.fetch_token pour échanger l'autorisation. dans cette réponse pour 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, vérifiez le serveur d'autorisation à l'aide de la bibliothèque googleauth de réponse. Utilisez la méthode authorizer.handle_auth_callback_deferred pour enregistrer le code d'autorisation et vous redirigez vers l'URL à l'origine de la demande d'autorisation. Ce reporte 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 getToken méthode:

const url = require('url');

// Receive the callback from Google's OAuth 2.0 server.
app.get('/oauth2callback', async (req, res) => {
  let q = url.parse(req.url, true).query;

  if (q.error) { // An error response e.g. error=access_denied
    console.log('Error:' + q.error);
  } else if (q.state !== req.session.state) { //check state value
    console.log('State mismatch. Possible CSRF attack');
    res.end('State mismatch. Possible CSRF attack');
  } else { // Get access and refresh tokens (if access_type is offline)

    let { tokens } = await oauth2Client.getToken(q.code);
    oauth2Client.setCredentials(tokens);
});

HTTP/REST

Pour échanger un code d'autorisation contre un jeton d'accès, appelez la méthode https://oauth2.googleapis.com/token et définissez les paramètres suivants:

Champs
client_id ID client obtenu à partir de l' API Console Credentials page
client_secret Code secret du client obtenu à partir du API Console Credentials page
code Code d'autorisation renvoyé par la requête initiale.
grant_type Tel que défini dans la norme OAuth 2.0 spécification, 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 la section API Console Credentials page pour la valeur client_id

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 accès de courte durée et un jeton d'actualisation. Notez que le jeton d'actualisation n'est renvoyé que si votre application définit access_type sur offline dans la demande initiale adressée au serveur d'autorisation.

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'au l'utilisateur révoque l'accès. Là encore, ce champ n'est présent dans cette réponse que si vous définissez access_type sur offline dans la requête initiale adressée au serveur d'autorisation de Google.
scope Les champs d'application d'accès accordés par le access_token, exprimés sous la forme d'une liste de délimitées par des espaces et sensibles à la casse.
token_type Type de jeton renvoyé. Pour le moment, la valeur de ce champ est toujours définie sur Bearer

L'extrait de code suivant présente 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 les problèmes suivants : au lieu de la réponse attendue. Les codes d'erreur courants et les solutions suggérées sont comme indiqué ci-dessous.

invalid_grant

Le code d'autorisation fourni n'est pas valide ou n'est pas au bon format. Demandez un nouveau code avant le Recommencer le processus OAuth pour demander le consentement de l'utilisateur à nouveau.

Appeler des API Google

PHP

Utilisez le jeton d'accès pour appeler les API Google en procédant comme suit:

  1. Si vous devez appliquer un jeton d'accès à un nouvel objet Google\Client (par exemple, exemple, si vous avez stocké le jeton d'accès dans une session utilisateur, utilisez Méthode setAccessToken:
    $client->setAccessToken($access_token);
  2. Créez un objet de service pour l'API que vous souhaitez appeler. Vous créez un objet de service en fournissant au constructeur un objet Google\Client autorisé pour l'API que vous que vous souhaitez appeler. Par exemple, pour appeler l'API Drive:
    $drive = new Google\Service\Drive($client);
  3. Envoyez des requêtes au service d'API à l'aide de la méthode 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 les requêtes API sur pour le compte d'un compte utilisateur ou d'un compte de service donné. Utiliser les identifiants d'autorisation spécifiques à l'utilisateur afin de créer un objet de service pour l'API que vous souhaitez appeler, puis d'utiliser cet objet pour des requêtes API autorisées.

  1. Créez un objet de service pour l'API que vous souhaitez appeler. Vous créez un objet de service en appelant la méthode build de la bibliothèque googleapiclient.discovery avec nom et version de l'API, ainsi que les identifiants de l'utilisateur: Par exemple, pour appeler la version 3 de l'API Drive:
    from googleapiclient.discovery import build
    
    drive = build('drive', 'v2', credentials=credentials)
  2. Envoyez des requêtes au service d'API à l'aide de la méthode 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 sur pour le compte d'un compte utilisateur ou d'un compte de service donné. Utiliser les identifiants d'autorisation spécifiques à l'utilisateur afin de créer un objet de service pour l'API que vous souhaitez appeler, puis d'utiliser cet objet pour des requêtes API autorisées.

  1. 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
  2. Définissez les identifiants sur le service:
    drive.authorization = credentials
  3. Envoyez des requêtes au service d'API à l'aide de la méthode fournies 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 accorder une autorisation pour chaque méthode en indiquant la méthode 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 des API Google. Votre application peut utiliser ce jeton pour autoriser les requêtes API au nom de pour un compte utilisateur ou 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 effectuer des appels vers pour le compte d'un service compte utilisateur si les niveaux d'accès requis par l'API ont été accordés. Pour ce faire, incluez le jeton d'accès dans une requête adressée à l'API en incluant une requête access_token ou une valeur Bearer d'en-tête HTTP Authorization. Si possible, l'en-tête HTTP est préférable, car les chaînes de requête ont tendance à être visibles dans les journaux du serveur. Dans la plupart des cas vous pouvez utiliser une bibliothèque cliente pour configurer vos appels aux API Google (par exemple, lorsque appelez l'API Drive Files).

Vous pouvez essayer toutes les API Google et consulter leurs champs d'application à la OAuth 2.0 Playground.

Exemples de requête HTTP GET

Un appel à la fonction drive.files (API Drive Files) via le protocole 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 à la même API pour l'utilisateur authentifié à l'aide de access_token. paramètre de chaîne de requête:

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curl exemples

Vous pouvez tester ces commandes avec l'application de ligne de commande curl. Voici un exemple qui utilise l'option d'en-tête HTTP (recommandé):

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 affiche une liste de fichiers au format JSON dans le Google Drive d'un utilisateur après la l'utilisateur s'authentifie et autorise l'application à accéder aux métadonnées Drive de l'utilisateur.

PHP

Pour exécuter cet exemple:

  1. Dans le fichier API Console, ajoutez l'URL de la machine locale au liste des URL de redirection. Par exemple, ajoutez http://localhost:8080.
  2. Créez un répertoire et accédez-y. Par exemple:
    mkdir ~/php-oauth2-example
    cd ~/php-oauth2-example
  3. Installez le client Google APIs Bibliothèque pour PHP à l'aide de Composer:
    composer require google/apiclient:^2.10
  4. Créer les fichiers index.php et oauth2callback.php avec le contenu ci-dessous.
  5. Exécutez l'exemple avec un serveur Web configuré pour diffuser PHP. Si vous utilisez PHP 5.6 ou une version ultérieure, vous pouvez utiliser le serveur Web de test intégré de PHP:
    php -S localhost:8080 ~/php-oauth2-example

index.php

<?php
require_once __DIR__.'/vendor/autoload.php';

session_start();

$client = new Google\Client();
$client->setAuthConfig('client_secrets.json');
$client->addScope(Google\Service\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'])) {
  // Generate and set state value
  $state = bin2hex(random_bytes(16));
  $client->setState($state);
  $_SESSION['state'] = $state;

  $auth_url = $client->createAuthUrl();
  header('Location: ' . filter_var($auth_url, FILTER_SANITIZE_URL));
} else {
  // Check the state value
  if (!isset($_GET['state']) || $_GET['state'] !== $_SESSION['state']) {
    die('State mismatch. Possible CSRF attack.');
  }
  $client->authenticate($_GET['code']);
  $_SESSION['access_token'] = $client->getAccessToken();
  $redirect_uri = 'http://' . $_SERVER['HTTP_HOST'] . '/';
  header('Location: ' . filter_var($redirect_uri, FILTER_SANITIZE_URL));
}

Python

Cet exemple utilise le framework Flask. Il exécute une application Web à l'adresse http://localhost:8080 qui vous permet de tester l'authentification OAuth 2.0 le flux de travail. 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 d'API. requête. Si nécessaire, il lance le flux d'autorisation. Si l'opération réussit, la page affiche le de l'API.
  • Tester directement le flux d'authentification:ce lien redirige vers une page qui tente d'envoyer l'utilisateur via le flux d'autorisation. L'application demande l'autorisation de envoyer des requêtes API autorisées au nom de l'utilisateur.
  • Révoquer les identifiants actuels:ce lien redirige vers une page qui révoque les autorisations que l'utilisateur a déjà accordées à l'application.
  • Effacer les identifiants de session Flask:ce lien efface les identifiants d'autorisation stockées dans la session Flask. Cela vous permet de voir ce qui se passerait si un utilisateur ayant déjà autorisé à votre appli a tenté d'exécuter une requête API dans une nouvelle session. Cela permet également vous voyez la réponse de l'API que votre application obtiendrait si un utilisateur avait révoqué les autorisations accordées à votre application, et votre application a quand même tenté d'autoriser une requête avec un jeton d'accès révoqué.
# -*- coding: utf-8 -*-

import os
import flask
import requests

import google.oauth2.credentials
import google_auth_oauthlib.flow
import googleapiclient.discovery

# This variable specifies the name of a file that contains the OAuth 2.0
# information for this application, including its client_id and client_secret.
CLIENT_SECRETS_FILE = "client_secret.json"

# This OAuth 2.0 access scope allows for full read/write access to the
# authenticated user's account and requires requests to use an SSL connection.
SCOPES = ['https://www.googleapis.com/auth/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:

  1. Dans API Console, ajoutez l'URL de la votre ordinateur local à la liste des URL de redirection. Par exemple, ajoutez http://localhost
  2. Assurez-vous de disposer d'une version LTS de maintenance, d'une version LTS active ou d'une version actuelle de Node.js installé
  3. Créez un répertoire et accédez-y. Par exemple:
    mkdir ~/nodejs-oauth2-example
    cd ~/nodejs-oauth2-example
  4. Install the Google API Client Library for Node.js using npm:
    npm install googleapis
  5. Créez les fichiers main.js avec le contenu ci-dessous.
  6. Exécutez l'exemple:
    node .\main.js

main.js

const http = require('http');
const https = require('https');
const url = require('url');
const { google } = require('googleapis');
const crypto = require('crypto');
const express = require('express');
const session = require('express-session');

/**
 * To use OAuth2 authentication, we need access to a CLIENT_ID, CLIENT_SECRET, AND REDIRECT_URI.
 * To get these credentials for your application, visit
 * https://console.cloud.google.com/apis/credentials.
 */
const oauth2Client = new google.auth.OAuth2(
  YOUR_CLIENT_ID,
  YOUR_CLIENT_SECRET,
  YOUR_REDIRECT_URL
);

// Access scopes for read-only Drive activity.
const scopes = [
  'https://www.googleapis.com/auth/drive.metadata.readonly'
];
/* Global variable that stores user credential in this code example.
 * ACTION ITEM for developers:
 *   Store user's refresh token in your data store if
 *   incorporating this code into your real app.
 *   For more information on handling refresh tokens,
 *   see https://github.com/googleapis/google-api-nodejs-client#handling-refresh-tokens
 */
let userCredential = null;

async function main() {
  const app = express();

  app.use(session({
    secret: 'your_secure_secret_key', // Replace with a strong secret
    resave: false,
    saveUninitialized: false,
  }));

  // Example on redirecting user to Google's OAuth 2.0 server.
  app.get('/', async (req, res) => {
    // Generate a secure random state value.
    const state = crypto.randomBytes(32).toString('hex');
    // Store state in the session
    req.session.state = state;

    // Generate a url that asks permissions for the Drive activity scope
    const authorizationUrl = oauth2Client.generateAuthUrl({
      // 'online' (default) or 'offline' (gets refresh_token)
      access_type: 'offline',
      /** Pass in the scopes array defined above.
        * Alternatively, if only one scope is needed, you can pass a scope URL as a string */
      scope: scopes,
      // Enable incremental authorization. Recommended as a best practice.
      include_granted_scopes: true,
      // Include the state parameter to reduce the risk of CSRF attacks.
      state: state
    });

    res.redirect(authorizationUrl);
  });

  // Receive the callback from Google's OAuth 2.0 server.
  app.get('/oauth2callback', async (req, res) => {
    // Handle the OAuth 2.0 server response
    let q = url.parse(req.url, true).query;

    if (q.error) { // An error response e.g. error=access_denied
      console.log('Error:' + q.error);
    } else if (q.state !== req.session.state) { //check state value
      console.log('State mismatch. Possible CSRF attack');
      res.end('State mismatch. Possible CSRF attack');
    } else { // Get access and refresh tokens (if access_type is offline)
      let { tokens } = await oauth2Client.getToken(q.code);
      oauth2Client.setCredentials(tokens);

      /** Save credential to the global variable in case access token was refreshed.
        * ACTION ITEM: In a production app, you likely want to save the refresh token
        *              in a secure persistent database instead. */
      userCredential = tokens;

      // Example of using Google Drive API to list filenames in user's Drive.
      const drive = google.drive('v3');
      drive.files.list({
        auth: oauth2Client,
        pageSize: 10,
        fields: 'nextPageToken, files(id, name)',
      }, (err1, res1) => {
        if (err1) return console.log('The API returned an error: ' + err1);
        const files = res1.data.files;
        if (files.length) {
          console.log('Files:');
          files.map((file) => {
            console.log(`${file.name} (${file.id})`);
          });
        } else {
          console.log('No files found.');
        }
      });
    }
  });

  // Example on revoking a token
  app.get('/revoke', async (req, res) => {
    // Build the string for the POST request
    let postData = "token=" + userCredential.access_token;

    // Options for POST request to Google's OAuth 2.0 server to revoke a token
    let postOptions = {
      host: 'oauth2.googleapis.com',
      port: '443',
      path: '/revoke',
      method: 'POST',
      headers: {
        'Content-Type': 'application/x-www-form-urlencoded',
        'Content-Length': Buffer.byteLength(postData)
      }
    };

    // Set up the request
    const postReq = https.request(postOptions, function (res) {
      res.setEncoding('utf8');
      res.on('data', d => {
        console.log('Response: ' + d);
      });
    });

    postReq.on('error', error => {
      console.log(error)
    });

    // Post the request with data
    postReq.write(postData);
    postReq.end();
  });


  const server = http.createServer(app);
  server.listen(80);
}
main().catch(console.error);

HTTP/REST

Cet exemple Python utilise le framework Flask. et la bibliothèque Requests pour illustrer flux Web 2.0. Nous vous recommandons d'utiliser la bibliothèque cliente des API Google pour Python pour ce flux. (Le 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:
    state = str(uuid.uuid4())
    flask.session['state'] = state
    auth_uri = ('https://accounts.google.com/o/oauth2/v2/auth?response_type=code'
                '&client_id={}&redirect_uri={}&scope={}&state={}').format(CLIENT_ID, REDIRECT_URI,
                                                                          SCOPE, state)
    return flask.redirect(auth_uri)
  else:
    if 'state' not in flask.request.args or flask.request.args['state'] != flask.session['state']:
      return 'State mismatch. Possible CSRF attack.', 400

    auth_code = flask.request.args.get('code')
    data = {'code': auth_code,
            'client_id': CLIENT_ID,
            'client_secret': CLIENT_SECRET,
            'redirect_uri': REDIRECT_URI,
            'grant_type': 'authorization_code'}
    r = requests.post('https://oauth2.googleapis.com/token', data=data)
    flask.session['credentials'] = r.text
    return flask.redirect(flask.url_for('index'))


if __name__ == '__main__':
  import uuid
  app.secret_key = str(uuid.uuid4())
  app.debug = False
  app.run()

Règles de validation de l'URI de redirection

Google applique les règles de validation suivantes pour rediriger les URI afin d'aider les développeurs pour assurer la sécurité de leurs applications. Vos URI de redirection doivent respecter ces règles. Voir RFC 3986 section 3 pour la définition du domaine, de l'hôte, du chemin d'accès, de la requête, du schéma et des informations relatives à l'utilisateur, mentionnée ci-dessous.

Règles de validation
Schéma

Les URI de redirection doivent utiliser le schéma HTTPS et non un protocole HTTP simple. URI Localhost (y compris URI d'adresse IP localhost) ne sont pas concernés par cette règle.

Hôte

Les hôtes ne peuvent pas être des adresses IP brutes. Les adresses IP Localhost sont exemptées de cette règle.

Domaine
  • Domaines de premier niveau d'hôte (Domaines de premier niveau) doit faire partie de la liste des suffixes publics.
  • Les domaines de l'hôte 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 possède le domaine. De plus, si une application propriétaire d'un domaine raccourci choisit de rediriger vers ce domaine, cet URI de redirection doit contenir soit “/google-callback/” dans son chemin d'accès ou se termine par “/google-callback”
  • Informations sur l'utilisateur

    Les URI de redirection ne peuvent pas contenir le sous-composant "userinfo".

    Chemin d'accès

    Les URI de redirection ne peuvent pas contenir de traversée de répertoire (également appelée "suivi en arrière-plan du répertoire"). qui est représenté par “/..” ou “\..”, ou son URL l'encodage.

    Query

    Les URI de redirection ne peuvent pas contenir ouvrir les redirections.

    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 (encodage de pourcentage non conforme à l'encodage d'URL) forme d'un signe de pourcentage suivi de deux chiffres hexadécimaux)
    • Caractères nuls (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és par des portées. Il est recommandé de demander une autorisation pour accéder aux ressources au moment où vous en avez besoin. Pour cela, le serveur d'autorisation de Google est compatible avec les autorisations incrémentielles. Cette fonctionnalité vous permet de demander des niveaux d'accès selon vos besoins. 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 niveaux d'accès accordés par l'utilisateur au projet.

    Par exemple, une application permettant aux utilisateurs de sampler des titres et de créer des mix n'aura peut-être besoin que de très peu de au moment de la connexion, peut-être rien de plus que le nom de la personne qui se connecte. Toutefois, l'enregistrement d'un mix complet nécessiterait d'avoir accès à leur Google Drive. La plupart des gens le trouveraient naturel s'ils ne sont invités à accéder à leur Google Drive que lorsque l'application en avaient besoin.

    Dans ce cas, au moment de la connexion, l'application peut demander le openid, puis les champs d'application profile pour effectuer une connexion de base, puis demanderont https://www.googleapis.com/auth/drive.file au moment de la première requête d'enregistrement d'une d'un ensemble de données complet.

    Pour implémenter une autorisation incrémentielle, vous devez suivre la procédure normale de demande d'accès mais assurez-vous que la demande d'autorisation inclut les champs d'application précédemment accordés. Ce 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 le nouvelle autorisation combinée.
    • Lorsque vous utilisez le jeton d'actualisation pour l'autorisation combinée afin d'obtenir un jeton d'accès, le jeton d'accès représente l'autorisation combinée et peut être utilisé pour n'importe quelle 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, 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 du client de bureau d'une application, puis accordé un autre champ d'application au même application via un client mobile, l'autorisation combinée inclut les deux champs d'application.
    • Si vous révoquez un jeton représentant une autorisation combinée, l'accès à toutes ces les champs d'application des autorisations pour le compte de l'utilisateur associé sont révoqués simultanément.

    Les exemples de code spécifiques au langage présentés à l'Étape 1: Définir les autorisations et l'exemple d'URL de redirection HTTP/REST à l'étape 2: Les redirections vers le serveur OAuth 2.0 de Google utilisent toutes une autorisation incrémentielle. Exemples de code ci-dessous montrent également le code à ajouter pour utiliser l'autorisation incrémentielle.

    PHP

    $client->setIncludeGrantedScopes(true);

    Python

    En Python, définissez l'argument de mot clé include_granted_scopes sur true pour vous assurer qu'une demande d'autorisation inclut les champs d'application précédemment accordés. Il est très possible que include_granted_scopes ne sera pas le seul argument de mot clé que vous définissez, car comme illustré dans l'exemple ci-dessous.

    authorization_url, state = flow.authorization_url(
        # Enable offline access so that you can refresh an access token without
        # re-prompting the user for permission. Recommended for web server apps.
        access_type='offline',
        # Enable incremental authorization. Recommended as a best practice.
        include_granted_scopes='true')

    Ruby

    auth_client.update!(
      :additional_parameters => {"include_granted_scopes" => "true"}
    )

    Node.js

    const authorizationUrl = oauth2Client.generateAuthUrl({
      // 'online' (default) or 'offline' (gets refresh_token)
      access_type: 'offline',
      /** Pass in the scopes array defined above.
        * Alternatively, if only one scope is needed, you can pass a scope URL as a string */
      scope: scopes,
      // Enable incremental authorization. Recommended as a best practice.
      include_granted_scopes: true
    });
    

    HTTP/REST

    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. Toi peut actualiser un jeton d'accès sans demander l'autorisation à l'utilisateur (y compris lorsqu'il est absente) 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 est actualisé le jeton d'accès selon les besoins, tant que vous configurez cet objet pour un accès hors connexion.
    • Si vous n'utilisez pas de bibliothèque cliente, vous devez définir le protocole HTTP access_type paramètre de requête vers offline lors de la redirection de l'utilisateur vers le serveur OAuth 2.0 de Google. Dans ce cas, le serveur d'autorisation de Google renvoie un d'actualiser le jeton lorsque vous échangez une autorisation du code pour un jeton d'accès. Si le jeton d'accès expire (ou à tout autre moment), vous devez utiliser un jeton d'actualisation pour obtenir un nouveau jeton d'accès.

    Toute application ayant besoin d'accéder à un compte Google API lorsque l'utilisateur n'est pas présent. Par exemple, une application qui effectue des services de sauvegarde exécute des actions à des moments prédéterminés doit pouvoir actualiser son jeton d'accès lorsque le 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 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 l'API. pour accéder aux API Google au nom de l'utilisateur lorsque celui-ci est hors connexion. L'objet client le jeton d'accès est actualisé 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'utilisateur l'autorisation. Il est possible que access_type ne soit pas le seul mot clé que vous avez défini, comme illustré dans l'exemple ci-dessous.

    authorization_url, state = flow.authorization_url(
        # Enable offline access so that you can refresh an access token without
        # re-prompting the user for permission. Recommended for web server apps.
        access_type='offline',
        # Enable incremental authorization. Recommended as a best practice.
        include_granted_scopes='true')

    Une fois qu'un utilisateur a accordé un accès hors connexion aux champs d'application demandés, vous pouvez continuer à utiliser l'API. pour accéder aux API Google au nom de l'utilisateur lorsque celui-ci est hors connexion. L'objet client le jeton d'accès est actualisé si nécessaire.

    Ruby

    Si votre application a besoin d'un accès hors connexion à une API Google, définissez le type d'accès du client API sur offline:

    auth_client.update!(
      :additional_parameters => {"access_type" => "offline"}
    )

    Une fois qu'un utilisateur a accordé un accès hors connexion aux champs d'application demandés, vous pouvez continuer à utiliser l'API. pour accéder aux API Google au nom de l'utilisateur lorsque celui-ci est hors connexion. L'objet client le jeton d'accès est actualisé si nécessaire.

    Node.js

    Si votre application a besoin d'un accès hors connexion à une API Google, définissez le type d'accès du client API sur offline:

    const authorizationUrl = oauth2Client.generateAuthUrl({
      // 'online' (default) or 'offline' (gets refresh_token)
      access_type: 'offline',
      /** Pass in the scopes array defined above.
        * Alternatively, if only one scope is needed, you can pass a scope URL as a string */
      scope: scopes,
      // Enable incremental authorization. Recommended as a best practice.
      include_granted_scopes: true
    });
    

    Une fois qu'un utilisateur a accordé un accès hors connexion aux champs d'application demandés, vous pouvez continuer à utiliser l'API. pour accéder aux API Google au nom de l'utilisateur lorsque celui-ci est hors connexion. L'objet client le jeton d'accès est actualisé si nécessaire.

    Les jetons d'accès expirent. Cette bibliothèque utilisera automatiquement un jeton d'actualisation pour obtenir un nouvel accès s'il est sur le point d'expirer. Un moyen simple de toujours stocker les jetons les plus récents consiste à 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 ne se produit que lors de la première autorisation, et vous devez avoir défini votre access_type à offline lors de l'appel de generateAuthUrl pour recevoir le jeton d'actualisation. Si vous avez déjà attribué à votre application les autorisations requises sans définir les contraintes appropriées pour recevoir un jeton d'actualisation, vous devez 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 obtenus et actualisés automatiquement dans le prochain appel de l'API.

    HTTP/REST

    Pour actualiser un jeton d'accès, votre application envoie un POST HTTPS au serveur d'autorisation de Google (https://oauth2.googleapis.com/token) qui comprend 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 En tant que définis dans le 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 La fonction renvoie un objet JSON contenant un nouveau jeton d'accès. L'extrait de code suivant montre un exemple 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. Enregistrer les jetons d'actualisation dans un espace de stockage à long terme et continuent à les utiliser tant qu'ils sont valides. Si votre application demande trop de jetons d'actualisation, il risque de dépasser ces limites, auquel cas les jetons d'actualisation plus anciens cesseront de fonctionner.

    Révoquer un jeton

    Dans certains cas, un utilisateur peut souhaiter révoquer l'accès accordé à une application. Un utilisateur peut révoquer l'accès en accédant à la page Paramètres du compte. Consultez le Supprimer de la section "Sites et applications tiers" applications ayant accès à votre compte pour en savoir plus.

    Une application peut également révoquer de manière programmatique l'accès qui lui est accordé. La révocation par programmation est importante lorsqu'un utilisateur se désabonne, supprime application ou les ressources d'API requises par une application ont changé de manière significative. Autrement dit, peut inclure une requête API pour garantir que les autorisations précédemment accordées accordées à l'application sont supprimées.

    PHP

    Pour révoquer un jeton de manière programmatique, appelez revokeToken():

    $client->revokeToken();

    Python

    Pour révoquer un jeton de façon programmatique, envoyez une requête à https://oauth2.googleapis.com/revoke, qui inclut le jeton en tant que paramètre et définit le 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 à oauth2.revoke point de terminaison:

    uri = URI('https://oauth2.googleapis.com/revoke')
    response = Net::HTTP.post_form(uri, 'token' => auth_client.access_token)
    

    Il peut s'agir d'un jeton d'accès ou d'un jeton d'actualisation. Si le jeton est un jeton d'accès et qu'il a un jeton d'actualisation correspondant, le jeton d'actualisation sera également révoqué.

    Si la révocation a bien été traitée, le code d'état de la réponse est 200 Pour les conditions d'erreur, un code d'état 400 est renvoyé, ainsi qu'une code d'erreur.

    Node.js

    Pour révoquer un jeton de manière programmatique, envoyez une requête HTTPS POST à /revoke point de terminaison:

    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 a un jeton d'actualisation correspondant, le jeton d'actualisation sera également révoqué.

    Si la révocation a bien été traitée, le code d'état de la réponse est 200 Pour les conditions d'erreur, un code d'état 400 est renvoyé, ainsi qu'une 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 possède le jeton d'actualisation correspondant, il sera également révoqué.

    Si la révocation a bien été traitée, le code d'état HTTP de la réponse est 200 Pour les conditions d'erreur, un code d'état HTTP 400 est renvoyé avec par un code d'erreur.

    Implémenter la protection multicompte

    Une mesure supplémentaire à prendre pour protéger l'expérience utilisateur implémente les stratégies d'enchères à l'aide du service de protection multicompte de Google. Ce service vous permet vous abonner aux notifications d'événements liés à la sécurité, qui fournissent des informations à votre application sur des modifications majeures au compte utilisateur. Vous pouvez ensuite utiliser ces informations pour prendre des mesures en fonction de comment vous décidez de répondre aux événements.

    Voici quelques exemples de types d'événements envoyés à votre application par le service de protection multicompte de Google:

    • https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
    • https://schemas.openid.net/secevent/oauth/event-type/token-revoked
    • https://schemas.openid.net/secevent/risc/event-type/account-disabled

    Consultez le Protéger les comptes utilisateur grâce à la page "Protection multicompte" pour en savoir plus sur l'implémentation de la protection multicompte et obtenir la liste complète des événements disponibles.