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 implémenter l'autorisation OAuth 2.0 pour accéder aux API Google.
OAuth 2.0 permet aux utilisateurs de partager des données spécifiques avec une application tout en préservant la confidentialité de leurs noms d'utilisateur, mots de passe et autres informations. Par exemple, une application peut utiliser OAuth 2.0 pour obtenir l'autorisation des utilisateurs de stocker des fichiers dans leurs Google Drives.
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 maintenir 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 que l'utilisateur a quitté l'application.
Les applications de serveur Web utilisent également fréquemment des comptes de service pour autoriser les demandes d'API, en particulier lors de l'appel d'API Cloud pour accéder aux données basées sur le projet plutôt qu'aux données spécifiques à l'utilisateur. Les applications de serveur Web peuvent utiliser des comptes de service conjointement avec l'autorisation d'utilisateur.
Bibliothèques clientes
Les exemples spécifiques au langage sur cette page utilisent les bibliothèques clientes de l'API Google pour implémenter l'autorisation OAuth 2.0. Pour exécuter les exemples de code, vous devez d'abord installer la bibliothèque cliente pour votre langue.
Lorsque vous utilisez une bibliothèque cliente d'API Google pour gérer le flux OAuth 2.0 de votre application, la bibliothèque cliente effectue de nombreuses actions que l'application devrait autrement gérer seule. Par exemple, il détermine quand l'application peut utiliser ou actualiser les jetons d'accès stockés ainsi que quand l'application doit obtenir à nouveau le consentement. La bibliothèque cliente génère également des URL de redirection correctes et aide à implémenter des gestionnaires de redirection qui échangent des codes d'autorisation contre des jetons d'accès.
Les bibliothèques clientes sont disponibles pour les langues suivantes :
Conditions préalables
Activer les API pour votre projet
Toute application qui appelle les API Google doit activer ces API dans le API Console.
Pour activer une API pour votre projet :
- Open the API Library dans le Google API Console.
- If prompted, select a project, or create a new one.
- Le API Library répertorie toutes les API disponibles, regroupées par famille de produits et popularité. Si l'API que vous souhaitez activer n'est pas visible dans la liste, utilisez la recherche pour la trouver ou cliquez sur Afficher tout 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 informations d'identification pour votre projet. Vos applications peuvent ensuite utiliser les informations d'identification pour accéder aux API que vous avez activées pour ce projet.
- Go to the Credentials page.
- Cliquez sur Créer des informations d'identification > ID client OAuth .
- Sélectionnez le type d'application Web .
- Remplissez le formulaire et 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, comme
http://localhost:8080. Dans cet esprit, veuillez noter que tous les exemples de ce document utilisenthttp://localhost:8080comme URI de redirection.Nous vous recommandons de concevoir les points de terminaison d'authentification de votre application afin que votre application n'expose pas de codes d'autorisation à d'autres ressources sur la page.
Après avoir créé vos informations d'identification, téléchargez le fichier client_secret.json à partir du API Console. Stockez le fichier en toute sécurité dans un emplacement auquel seule votre application peut accéder.
Identifier les étendues d'accès
Les étendues permettent à votre application de demander uniquement l'accès aux ressources dont elle a besoin tout en permettant également aux utilisateurs de contrôler la quantité d'accès qu'ils accordent à votre application. Ainsi, il peut exister une relation inverse entre le nombre de portées demandées 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 étendues auxquelles votre application aura besoin d'une autorisation pour accéder.
Nous recommandons également que votre application demande l'accès aux étendues d'autorisation via un processus d' autorisation incrémentiel , dans lequel votre application demande l'accès aux données utilisateur en contexte. Cette meilleure pratique aide les utilisateurs à comprendre plus facilement pourquoi votre application a besoin de l'accès qu'elle demande.
Le document OAuth 2.0 API Scopes contient une liste complète des champs d'application que vous pouvez utiliser pour accéder aux API Google.
Exigences spécifiques à la langue
Pour exécuter l'un des exemples de code de ce document, vous aurez besoin d'un compte Google, d'un accès à Internet et d'un navigateur Web. Si vous utilisez l'une des bibliothèques clientes d'API, consultez également les exigences spécifiques au langage ci-dessous.
PHP
Pour exécuter les exemples de code PHP dans ce document, vous aurez besoin de :
- PHP 5.4 ou supérieur avec l'interface de ligne de commande (CLI) et l'extension JSON installées.
- L'outil de gestion des dépendances Composer .
La bibliothèque cliente des API Google pour PHP :
php composer.phar require google/apiclient:^2.0
Python
Pour exécuter les exemples de code Python de ce document, vous aurez besoin de :
- Python 2.6 ou supérieur
- L'outil de gestion de paquet pip .
- La bibliothèque cliente des API Google pour Python :
pip install --upgrade google-api-python-client
-
google-auth,google-auth-oauthlibetgoogle-auth-httplib2pour l'autorisation de l'utilisateur.pip install --upgrade google-auth google-auth-oauthlib google-auth-httplib2
- Le cadre d'application Web Flask Python.
pip install --upgrade flask
- La bibliothèque HTTP des
requests.pip install --upgrade requests
Rubis
Pour exécuter les exemples de code Ruby de ce document, vous aurez besoin de :
- Ruby 2.2.2 ou supérieur
La bibliothèque cliente des API Google pour Ruby :
gem install google-api-client
Le cadre d'application Web Sinatra Ruby.
gem install sinatra
HTTP/REST
Vous n'avez pas besoin d'installer de bibliothèques pour pouvoir appeler directement les points de terminaison OAuth 2.0.
Obtention de 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 afin d'effectuer une demande d'API au nom de l'utilisateur. Votre application doit disposer de ce consentement avant de pouvoir exécuter une requête d'API Google nécessitant l'autorisation de l'utilisateur.
La liste ci-dessous résume rapidement ces étapes :
- Votre application identifie les autorisations dont elle a besoin.
- Votre application redirige l'utilisateur vers Google avec la liste des autorisations demandées.
- L'utilisateur décide d'accorder ou non les autorisations à votre application.
- Votre application dé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 demandes d'API au nom de l'utilisateur.
Étape 1 : Définir les paramètres d'autorisation
Votre première étape consiste à créer la demande d'autorisation. Cette demande définit des paramètres qui identifient votre application et définissent 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 les paramètres sur cette URL.
Les onglets ci-dessous définissent les paramètres d'autorisation pris en charge pour les applications de serveur Web. Les exemples spécifiques 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 demande d'autorisation.
Cet objet utilise les informations de votre fichier client_secret.json pour identifier votre application. (Voir création d'informations d' identification d'autorisation pour en savoir plus sur ce fichier.) L'objet identifie également les étendues auxquelles votre application demande l'autorisation d'accéder et l'URL du point de terminaison d'authentification de votre application, qui gérera la réponse du serveur OAuth 2.0 de Google. Enfin, le code définit les access_type 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" ensures that your application always receives a refresh token.
// If you are not using offline access, you can omit this.
$client->setApprovalPrompt("consent");
$client->setIncludeGrantedScopes(true); // incremental authLa demande précise les informations suivantes :
| Paramètres | |||||||
|---|---|---|---|---|---|---|---|
client_id | Obligatoire L'ID client de votre application. Vous pouvez trouver cette valeur dans le API Console Credentials page. En PHP, appelez la fonction
$client = new Google_Client();
$client->setAuthConfig('client_secret.json'); | ||||||
redirect_uri | Obligatoire Détermine où le serveur d'API redirige l'utilisateur une fois que l'utilisateur a terminé le 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 API Console Credentials page de votre client. Si cette valeur ne correspond pas à un URI de redirection autorisé pour le Notez que le schéma Pour définir cette valeur en PHP, appelez la fonction
$client->setRedirectUri('https://oauth2.example.com/code'); | ||||||
scope | Obligatoire Une liste d'étendues délimitées par des espaces qui identifient les ressources auxquelles votre application peut accéder au nom de l'utilisateur. Ces valeurs informent l'écran de consentement que Google affiche à l'utilisateur. Les étendues permettent à votre application de demander uniquement l'accès aux ressources dont elle a besoin tout en permettant également aux utilisateurs de contrôler la quantité d'accès qu'ils accordent à votre application. Ainsi, il existe une relation inverse entre le nombre de portées demandées et la probabilité d'obtenir le consentement de l'utilisateur. Pour définir cette valeur en PHP, appelez la fonction $client->addScope(Google_Service_Drive::DRIVE_METADATA_READONLY); Nous recommandons que votre application demande l'accès aux étendues d'autorisation en contexte dans la mesure du possible. En demandant l'accès aux données utilisateur en contexte, via une autorisation incrémentielle , vous aidez les utilisateurs à comprendre plus facilement pourquoi votre application a besoin de l'accès qu'elle demande. | ||||||
access_type | conseillé 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 Définissez la valeur sur Pour définir cette valeur en PHP, appelez la fonction
$client->setAccessType('offline'); | ||||||
state | conseillé Spécifie toute valeur de chaîne que votre application utilise pour maintenir l'état entre votre demande d'autorisation et la réponse du serveur d'autorisation. Le serveur renvoie la valeur exacte que vous envoyez sous forme de paire Vous pouvez utiliser ce paramètre à plusieurs fins, telles que diriger l'utilisateur vers la ressource appropriée dans votre application, envoyer des nonces et atténuer la falsification des demandes intersites. Étant donné que votre Pour définir cette valeur en PHP, appelez la fonction $client->setState($sample_passthrough_value); | ||||||
include_granted_scopes | Optionnel Permet aux applications d'utiliser une autorisation incrémentielle pour demander l'accès à des étendues supplémentaires en contexte. Si vous définissez la valeur de ce paramètre sur Pour définir cette valeur en PHP, appelez la fonction $client->setIncludeGrantedScopes(true); | ||||||
login_hint | Optionnel Si votre application sait quel utilisateur essaie 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 flux de connexion, soit en préremplissant le champ e-mail dans le formulaire de connexion, soit en sélectionnant la session multi-connexion appropriée. Définissez la valeur du paramètre sur une adresse e-mail ou un Pour définir cette valeur en PHP, appelez la fonction
$client->setLoginHint('None'); | ||||||
prompt | Optionnel Une liste d'invites, délimitée par des espaces et sensible à la casse, à présenter à l'utilisateur. Si vous ne spécifiez pas ce paramètre, l'utilisateur sera invité uniquement la première fois que votre projet demande l'accès. Voir Demander un nouveau consentement pour plus d'informations. Pour définir cette valeur en PHP, appelez la fonction
$client->setApprovalPrompt('consent');Les valeurs possibles sont :
| ||||||
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 des informations du fichier client_secret.json que vous avez téléchargé après avoir créé les informations d'identification d'autorisation . Cet objet identifie également les étendues auxquelles votre application demande l'autorisation d'accéder et l'URL du point de terminaison d'authentification de votre application, qui gérera la réponse du serveur OAuth 2.0 de Google. Enfin, le code définit les access_type 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 demande précise les informations suivantes :
| Paramètres | |||||||
|---|---|---|---|---|---|---|---|
client_id | Obligatoire L'ID client de votre application. Vous pouvez trouver cette valeur dans le API Console Credentials page. En Python, appelez la méthode
flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
'client_secret.json',
scopes=['https://www.googleapis.com/auth/drive.metadata.readonly']) | ||||||
redirect_uri | Obligatoire Détermine où le serveur d'API redirige l'utilisateur une fois que l'utilisateur a terminé le 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 API Console Credentials page de votre client. Si cette valeur ne correspond pas à un URI de redirection autorisé pour le Notez que le schéma Pour définir cette valeur en Python, définissez la propriété flow.redirect_uri = 'https://oauth2.example.com/code' | ||||||
scope | Obligatoire Une liste d'étendues qui identifient les ressources auxquelles votre application peut accéder au nom de l'utilisateur. Ces valeurs informent l'écran de consentement que Google affiche à l'utilisateur. Les étendues permettent à votre application de demander uniquement l'accès aux ressources dont elle a besoin tout en permettant également aux utilisateurs de contrôler la quantité d'accès qu'ils accordent à votre application. Ainsi, il existe une relation inverse entre le nombre de portées demandées et la probabilité d'obtenir le consentement de l'utilisateur. En Python, utilisez la même méthode que vous utilisez pour définir le
flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
'client_secret.json',
scopes=['https://www.googleapis.com/auth/drive.metadata.readonly'])Nous recommandons que votre application demande l'accès aux étendues d'autorisation en contexte dans la mesure du possible. En demandant l'accès aux données utilisateur en contexte, via une autorisation incrémentielle , vous aidez les utilisateurs à comprendre plus facilement pourquoi votre application a besoin de l'accès qu'elle demande. | ||||||
access_type | conseillé 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 Définissez la valeur sur En Python, définissez le paramètre
authorization_url, state = flow.authorization_url(
access_type='offline',
include_granted_scopes='true') | ||||||
state | conseillé Spécifie toute valeur de chaîne que votre application utilise pour maintenir l'état entre votre demande d'autorisation et la réponse du serveur d'autorisation. Le serveur renvoie la valeur exacte que vous envoyez sous forme de paire Vous pouvez utiliser ce paramètre à plusieurs fins, telles que diriger l'utilisateur vers la ressource appropriée dans votre application, envoyer des nonces et atténuer la falsification des demandes intersites. Étant donné que votre En Python, définissez le paramètre
authorization_url, state = flow.authorization_url(
access_type='offline',
state=sample_passthrough_value,
include_granted_scopes='true') | ||||||
include_granted_scopes | Optionnel Permet aux applications d'utiliser une autorisation incrémentielle pour demander l'accès à des étendues supplémentaires en contexte. Si vous définissez la valeur de ce paramètre sur En Python, définissez le paramètre
authorization_url, state = flow.authorization_url(
access_type='offline',
include_granted_scopes='true') | ||||||
login_hint | Optionnel Si votre application sait quel utilisateur essaie 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 flux de connexion, soit en préremplissant le champ e-mail dans le formulaire de connexion, soit en sélectionnant la session multi-connexion appropriée. Définissez la valeur du paramètre sur une adresse e-mail ou un En Python, définissez le paramètre
authorization_url, state = flow.authorization_url(
access_type='offline',
login_hint='None',
include_granted_scopes='true') | ||||||
prompt | Optionnel Une liste d'invites, délimitée par des espaces et sensible à la casse, à présenter à l'utilisateur. Si vous ne spécifiez pas ce paramètre, l'utilisateur sera invité uniquement la première fois que votre projet demande l'accès. Voir Demander un nouveau consentement pour plus d'informations. En Python, définissez le paramètre
authorization_url, state = flow.authorization_url(
access_type='offline',
prompt='consent',
include_granted_scopes='true')Les valeurs possibles sont :
| ||||||
Rubis
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 étendues auxquelles 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_v2'
require 'google/api_client/client_secrets'
client_secrets = Google::APIClient::ClientSecrets.load
auth_client = client_secrets.to_authorization
auth_client.update!(
:scope => 'https://www.googleapis.com/auth/drive.metadata.readonly',
:redirect_uri => 'http://www.example.com/oauth2callback',
:additional_parameters => {
"access_type" => "offline", # offline access
"include_granted_scopes" => "true" # incremental auth
}
)Votre application utilise l'objet client pour effectuer des opérations OAuth 2.0, telles que la génération d'URL de demande d'autorisation et l'application de jetons d'accès aux demandes HTTP.
HTTP/REST
Le point de terminaison OAuth 2.0 de Google se trouve à l' https://accounts.google.com/o/oauth2/v2/auth . Ce point de terminaison est accessible uniquement via HTTPS. Les connexions HTTP simples sont refusées.
Le serveur d'autorisation Google prend en charge les paramètres de chaîne de requête suivants pour les applications de serveur Web :
| Paramètres | |||||||
|---|---|---|---|---|---|---|---|
client_id | Obligatoire L'ID client de votre application. Vous pouvez trouver cette valeur dans le API Console Credentials page. | ||||||
redirect_uri | Obligatoire Détermine où le serveur d'API redirige l'utilisateur une fois que l'utilisateur 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 API Console Credentials page de votre client. Si cette valeur ne correspond pas à un URI de redirection autorisé pour le Notez que le schéma | ||||||
response_type | Obligatoire Détermine si le point de terminaison Google OAuth 2.0 renvoie un code d'autorisation. Définissez la valeur du paramètre sur le | ||||||
scope | Obligatoire Une liste d'étendues délimitées par des espaces qui identifient les ressources auxquelles votre application peut accéder au nom de l'utilisateur. Ces valeurs informent l'écran de consentement que Google affiche à l'utilisateur. Les étendues permettent à votre application de demander uniquement l'accès aux ressources dont elle a besoin tout en permettant également aux utilisateurs de contrôler la quantité d'accès qu'ils accordent à votre application. Ainsi, il existe une relation inverse entre le nombre de portées demandées et la probabilité d'obtenir le consentement de l'utilisateur. Nous recommandons que votre application demande l'accès aux étendues d'autorisation en contexte dans la mesure du possible. En demandant l'accès aux données utilisateur en contexte, via une autorisation incrémentielle , vous aidez les utilisateurs à comprendre plus facilement pourquoi votre application a besoin de l'accès qu'elle demande. | ||||||
access_type | conseillé 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 Définissez la valeur sur | ||||||
state | conseillé Spécifie toute valeur de chaîne que votre application utilise pour maintenir l'état entre votre demande d'autorisation et la réponse du serveur d'autorisation. Le serveur renvoie la valeur exacte que vous envoyez sous forme de paire Vous pouvez utiliser ce paramètre à plusieurs fins, telles que diriger l'utilisateur vers la ressource appropriée dans votre application, envoyer des nonces et atténuer la falsification des demandes intersites. Étant donné que votre | ||||||
include_granted_scopes | Optionnel Permet aux applications d'utiliser une autorisation incrémentielle pour demander l'accès à des étendues supplémentaires en contexte. Si vous définissez la valeur de ce paramètre sur | ||||||
login_hint | Optionnel Si votre application sait quel utilisateur essaie 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 flux de connexion, soit en préremplissant le champ e-mail dans le formulaire de connexion, soit en sélectionnant la session multi-connexion appropriée. Définissez la valeur du paramètre sur une adresse e-mail ou un | ||||||
prompt | Optionnel Une liste d'invites, délimitée par des espaces et sensible à la casse, à présenter à l'utilisateur. Si vous ne spécifiez pas ce paramètre, l'utilisateur sera invité uniquement la première fois que votre projet demande l'accès. Voir Demander un nouveau consentement pour plus d'informations. Les valeurs possibles sont :
| ||||||
Étape 2 : Redirection vers le serveur OAuth 2.0 de Google
Redirigez l'utilisateur vers le serveur OAuth 2.0 de Google pour lancer le processus d'authentification et d'autorisation. En général, cela se produit lorsque votre application doit d'abord accéder 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 l'autorisation d'accéder.
PHP
- Générez une URL pour demander l'accès au serveur OAuth 2.0 de Google :
$auth_url = $client->createAuthUrl();
- Rediriger l'utilisateur vers
$auth_url:header('Location: ' . filter_var($auth_url, FILTER_SANITIZE_URL));
Python
Cet exemple montre comment rediriger l'utilisateur vers l'URL d'autorisation à l'aide du framework d'application Web Flask :
return flask.redirect(authorization_url)
Rubis
- Générez une URL pour demander l'accès au serveur OAuth 2.0 de Google :
auth_uri = auth_client.authorization_uri.to_s
- Redirigez l'utilisateur vers
auth_uri.
HTTP/REST
Exemple de redirection vers le serveur d'autorisation de Google
Un exemple d'URL est présenté ci-dessous, avec des sauts de ligne et des espaces pour plus de lisibilité.
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly& access_type=offline& include_granted_scopes=true& response_type=code& state=state_parameter_passthrough_value& redirect_uri=https%3A//oauth2.example.com/code& client_id=client_id
Après avoir créé l'URL de demande, redirigez l'utilisateur vers celle-ci.
Le serveur OAuth 2.0 de Google authentifie l'utilisateur et obtient le consentement de l'utilisateur pour que votre application accède aux étendues demandées. 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
Dans cette étape, l'utilisateur décide s'il accorde à votre application l'accès demandé. À ce stade, Google affiche une fenêtre de consentement qui indique le nom de votre application et les services d'API Google auxquels il demande l'autorisation d'accéder avec les identifiants d'autorisation de l'utilisateur et un résumé des étendues d'accès à accorder. L'utilisateur peut alors consentir à accorder l'accès à un ou plusieurs périmètres demandés par votre application ou refuser la demande.
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.
les erreurs
Les demandes adressées au point de terminaison d'autorisation OAuth 2.0 de Google peuvent afficher des messages d'erreur destinés à l'utilisateur au lieu des flux d'authentification et d'autorisation attendus. Les codes d'erreur courants et les résolutions suggérées sont répertoriés ci-dessous.
admin_policy_enforced
Le compte Google n'est pas en mesure d'autoriser un ou plusieurs champs d'application demandés en raison des politiques de son administrateur Google Workspace. Consultez l'article d'aide Google Workspace Admin Contrôler quelles applications tierces et internes accèdent aux données Google Workspace pour plus d'informations sur la façon dont un administrateur peut restreindre l'accès à toutes les étendues ou aux étendues sensibles et restreintes jusqu'à ce que l'accès soit explicitement accordé à votre ID client OAuth.
disallowed_useragent
Le point de terminaison d'autorisation est affiché dans un user-agent intégré interdit par les règles OAuth 2.0 de Google.
Android
Les développeurs Android peuvent rencontrer ce message d'erreur lors de l'ouverture 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 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 agent utilisateur intégré et qu'un utilisateur accède au point de terminaison d'autorisation OAuth 2.0 de Google à partir de votre site. Les développeurs doivent autoriser l'ouverture de liens généraux dans le gestionnaire de liens par défaut du système d'exploitation, qui inclut à la foisles gestionnaires deliens d'application Android ou l'application de navigateur par défaut. La bibliothèque Android Custom Tabs est également une option prise en charge.
iOS
Les développeurs iOS et macOS peuvent rencontrer cette erreur lors de l'ouverture des demandes d'autorisation dans WKWebView . Les développeurs doivent plutôt utiliser des bibliothèques iOS telles que Google Sign-In pour iOS ou AppAuth d' OpenID Foundation 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 agent utilisateur intégré et qu'un utilisateur accède au point de terminaison d'autorisation OAuth 2.0 de Google à partir de votre site. Les développeurs doivent autoriser l'ouverture de liens généraux dans le gestionnaire de liens par défaut du système d'exploitation, qui inclut à la foisles gestionnaires deliens universels ou l'application de navigateur par défaut. La bibliothèque SFSafariViewController est également une option prise en charge.
org_internal
L'ID client OAuth dans la demande fait partie d'un projet limitant l'accès aux comptes Google dans une organisation Google Cloud spécifique. Pour plus d'informations sur cette option de configuration, consultez la section Type d'utilisateur dans l'article d'aide Configuration de votre écran de consentement OAuth.
redirect_uri_mismatch
Le redirect_uri transmis dans la demande d'autorisation ne correspond pas à un URI de redirection autorisé pour l'ID client OAuth. Examinez les URI de redirection autorisés dans le Google API Console Credentials page.
É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. 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
Une réponse de code d'autorisation :
https://oauth2.example.com/auth?code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7
Exemple de réponse de 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
After completing the OAuth 2.0 flow, you should be redirected to http://localhost/oauth2callback , which will likely yield a 404 NOT FOUND error unless your local machine serves a file at that address. The next step provides more detail about the information returned in the URI when the user is redirected back to your application.
Step 5: Exchange authorization code for refresh and access tokens
After the web server receives the authorization code, it can exchange the authorization code for an access token.
PHP
To exchange an authorization code for an access token, use the authenticate method:
$client->authenticate($_GET['code']);
You can retrieve the access token with the getAccessToken method:
$access_token = $client->getAccessToken();
Python
On your callback page, use the google-auth library to verify the authorization server response. Then, use the flow.fetch_token method to exchange the authorization code in that response for an access token:
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
To exchange an authorization code for an access token, use the fetch_access_token! method:
auth_client.code = auth_code auth_client.fetch_access_token!
HTTP/REST
To exchange an authorization code for an access token, call the https://oauth2.googleapis.com/token endpoint and set the following parameters:
| Fields | |
|---|---|
client_id | The client ID obtained from the API Console Credentials page. |
client_secret | The client secret obtained from the API Console Credentials page. |
code | The authorization code returned from the initial request. |
grant_type | As defined in the OAuth 2.0 specification , this field's value must be set to authorization_code . |
redirect_uri | One of the redirect URIs listed for your project in the API Console Credentials page for the given client_id . |
The following snippet shows a sample request:
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 responds to this request by returning a JSON object that contains a short-lived access token and a refresh token. Note that the refresh token is only returned if your application set the access_type parameter to offline in the initial request to Google's authorization server .
The response contains the following fields:
| Fields | |
|---|---|
access_token | The token that your application sends to authorize a Google API request. |
expires_in | The remaining lifetime of the access token in seconds. |
refresh_token | A token that you can use to obtain a new access token. Refresh tokens are valid until the user revokes access. Again, this field is only present in this response if you set the access_type parameter to offline in the initial request to Google's authorization server. |
scope | The scopes of access granted by the access_token expressed as a list of space-delimited, case-sensitive strings. |
token_type | The type of token returned. At this time, this field's value is always set to Bearer . |
The following snippet shows a sample response:
{
"access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
"expires_in": 3920,
"token_type": "Bearer",
"scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
"refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}Calling Google APIs
PHP
Use the access token to call Google APIs by completing the following steps:
- If you need to apply an access token to a new
Google_Clientobject—for example, if you stored the access token in a user session—use thesetAccessTokenmethod:$client->setAccessToken($access_token);
- Build a service object for the API that you want to call. You build a service object by providing an authorized
Google_Clientobject to the constructor for the API you want to call. For example, to call the Drive API:$drive = new Google_Service_Drive($client);
- Make requests to the API service using the interface provided by the service object . For example, to list the files in the authenticated user's Google Drive:
$files = $drive->files->listFiles(array())->getItems();
Python
After obtaining an access token, your application can use that token to authorize API requests on behalf of a given user account or service account. Use the user-specific authorization credentials to build a service object for the API that you want to call, and then use that object to make authorized API requests.
- Build a service object for the API that you want to call. You build a service object by calling the
googleapiclient.discoverylibrary'sbuildmethod with the name and version of the API and the user credentials: For example, to call version 2 of the Drive API:from googleapiclient.discovery import build drive = build('drive', 'v2', credentials=credentials) - Make requests to the API service using the interface provided by the service object . For example, to list the files in the authenticated user's Google Drive:
files = drive.files().list().execute()
Ruby
Use the auth_client object to call Google APIs by completing the following steps:
- Build a service object for the API that you want to call. For example, to call version 2 of the Drive API:
drive = Google::Apis::DriveV2::DriveService.new
- Set the credentials on the service:
drive.authorization = auth_client
- Make requests to the API service using the interface provided by the service object . For example, to list the files in the authenticated user's Google Drive:
files = drive.list_files
Alternately, authorization can be provided on a per-method basis by supplying the options parameter to a method:
files = drive.list_files(options: { authorization: auth_client })HTTP/REST
After your application obtains an access token, you can use the token to make calls to a Google API on behalf of a given user account if the scope(s) of access required by the API have been granted. To do this, include the access token in a request to the API by including either an access_token query parameter or an Authorization HTTP header Bearer value. When possible, the HTTP header is preferable, because query strings tend to be visible in server logs. In most cases you can use a client library to set up your calls to Google APIs (for example, when calling the Drive Files API ).
You can try out all the Google APIs and view their scopes at the OAuth 2.0 Playground .
HTTP GET examples
A call to the drive.files endpoint (the Drive Files API) using the Authorization: Bearer HTTP header might look like the following. Note that you need to specify your own access token:
GET /drive/v2/files HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
Here is a call to the same API for the authenticated user using the access_token query string parameter:
GET https://www.googleapis.com/drive/v2/files?access_token=access_token
curl examples
You can test these commands with the curl command-line application. Here's an example that uses the HTTP header option (preferred):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files
Or, alternatively, the query string parameter option:
curl https://www.googleapis.com/drive/v2/files?access_token=access_token
Complete example
The following example prints a JSON-formatted list of files in a user's Google Drive after the user authenticates and gives consent for the application to access the user's Drive metadata.
PHP
To run this example:
- In the API Console, add the URL of the local machine to the list of redirect URLs. For example, add
http://localhost:8080. - Create a new directory and change to it. For example:
mkdir ~/php-oauth2-example cd ~/php-oauth2-example
- Install the Google API Client Library for PHP using Composer :
composer require google/apiclient:^2.0
- Create the files
index.phpandoauth2callback.phpwith the content below. - Run the example with a web server configured to serve PHP. If you use PHP 5.4 or newer, you can use PHP's built-in test web server:
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
This example uses the Flask framework. It runs a web application at http://localhost:8080 that lets you test the OAuth 2.0 flow. If you go to that URL, you should see four links:
- Test an API request: This link points to a page that tries to execute a sample API request. If necessary, it starts the authorization flow. If successful, the page displays the API response.
- Test the auth flow directly: This link points to a page that tries to send the user through the authorization flow . The app requests permission to submit authorized API requests on the user's behalf.
- Revoke current credentials: This link points to a page that revokes permissions that the user has already granted to the application.
- Clear Flask session credentials: This link clears authorization credentials that are stored in the Flask session. This lets you see what would happen if a user who had already granted permission to your app tried to execute an API request in a new session. It also lets you see the API response your app would get if a user had revoked permissions granted to your app, and your app still tried to authorize a request with a revoked access token.
# -*- 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
This example uses the Sinatra framework.
require 'google/apis/drive_v2'
require 'google/api_client/client_secrets'
require 'json'
require 'sinatra'
enable :sessions
set :session_secret, 'setme'
get '/' do
unless session.has_key?(:credentials)
redirect to('/oauth2callback')
end
client_opts = JSON.parse(session[:credentials])
auth_client = Signet::OAuth2::Client.new(client_opts)
drive = Google::Apis::DriveV2::DriveService.new
files = drive.list_files(options: { authorization: auth_client })
"<pre>#{JSON.pretty_generate(files.to_h)}</pre>"
end
get '/oauth2callback' do
client_secrets = Google::APIClient::ClientSecrets.load
auth_client = client_secrets.to_authorization
auth_client.update!(
:scope => 'https://www.googleapis.com/auth/drive.metadata.readonly',
:redirect_uri => url('/oauth2callback'))
if request['code'] == nil
auth_uri = auth_client.authorization_uri.to_s
redirect to(auth_uri)
else
auth_client.code = request['code']
auth_client.fetch_access_token!
auth_client.client_secret = nil
session[:credentials] = auth_client.to_json
redirect to('/')
end
endHTTP/REST
This Python example uses the Flask framework and the Requests library to demonstrate the OAuth 2.0 web flow. We recommend using the Google API Client Library for Python for this flow. (The example in the Python tab does use the client library.)
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()Redirect URI validation rules
Google applies the following validation rules to redirect URIs in order to help developers keep their applications secure. Your redirect URIs must adhere to these rules. See RFC 3986 section 3 for the definition of domain, host, path, query, scheme and userinfo, mentioned below.
| Validation rules | |
|---|---|
| Scheme | URIs must use the HTTPS scheme, not plain HTTP. Localhost URIs (including localhost IP address URIs) are exempt from this rule. |
| Host | Hosts cannot be raw IP addresses. Localhost IP addresses are exempted from this rule. |
| Domain | “googleusercontent.com” .goo.gl ) unless the app owns the domain. Furthermore, if an app that owns a shortener domain chooses to redirect to that domain, that redirect URI must either contain “/google-callback/” in its path or end with “/google-callback” . |
| Userinfo | Redirect URIs cannot contain the userinfo subcomponent. |
| Path | Redirect URIs cannot contain a path traversal (also called directory backtracking), which is represented by an |
| Query | Redirect URIs cannot contain open redirects . |
| Characters | URIs cannot contain certain characters including:
|
Incremental authorization
In the OAuth 2.0 protocol, your app requests authorization to access resources, which are identified by scopes. It is considered a best user-experience practice to request authorization for resources at the time you need them. To enable that practice, Google's authorization server supports incremental authorization. This feature lets you request scopes as they are needed and, if the user grants permission for the new scope, returns an authorization code that may be exchanged for a token containing all scopes the user has granted the project.
For example, an app that lets people sample music tracks and create mixes might need very few resources at sign-in time, perhaps nothing more than the name of the person signing in. However, saving a completed mix would require access to their Google Drive. Most people would find it natural if they only were asked for access to their Google Drive at the time the app actually needed it.
In this case, at sign-in time the app might request the openid and profile scopes to perform basic sign-in, and then later request the https://www.googleapis.com/auth/drive.file scope at the time of the first request to save a mix.
To implement incremental authorization, you complete the normal flow for requesting an access token but make sure that the authorization request includes previously granted scopes. This approach allows your app to avoid having to manage multiple access tokens.
The following rules apply to an access token obtained from an incremental authorization:
- The token can be used to access resources corresponding to any of the scopes rolled into the new, combined authorization.
- When you use the refresh token for the combined authorization to obtain an access token, the access token represents the combined authorization and can be used for any of the
scopevalues included in the response. - The combined authorization includes all scopes that the user granted to the API project even if the grants were requested from different clients. For example, if a user granted access to one scope using an application's desktop client and then granted another scope to the same application via a mobile client, the combined authorization would include both scopes.
- If you revoke a token that represents a combined authorization, access to all of that authorization's scopes on behalf of the associated user are revoked simultaneously.
The language-specific code samples in Step 1: Set authorization parameters and the sample HTTP/REST redirect URL in Step 2: Redirect to Google's OAuth 2.0 server all use incremental authorization. The code samples below also show the code that you need to add to use incremental authorization.
PHP
$client->setIncludeGrantedScopes(true);
Python
In Python, set the include_granted_scopes keyword argument to true to ensure that an authorization request includes previously granted scopes. It is very possible that include_granted_scopes will not be the only keyword argument that you set, as shown in the example below.
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"}
)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
Refreshing an access token (offline access)
Access tokens periodically expire and become invalid credentials for a related API request. You can refresh an access token without prompting the user for permission (including when the user is not present) if you requested offline access to the scopes associated with the token.
- If you use a Google API Client Library, the client object refreshes the access token as needed as long as you configure that object for offline access.
- If you are not using a client library, you need to set the
access_typeHTTP query parameter toofflinewhen redirecting the user to Google's OAuth 2.0 server . In that case, Google's authorization server returns a refresh token when you exchange an authorization code for an access token. Then, if the access token expires (or at any other time), you can use a refresh token to obtain a new access token.
Requesting offline access is a requirement for any application that needs to access a Google API when the user is not present. For example, an app that performs backup services or executes actions at predetermined times needs to be able to refresh its access token when the user is not present. The default style of access is called online .
Server-side web applications, installed applications, and devices all obtain refresh tokens during the authorization process. Refresh tokens are not typically used in client-side (JavaScript) web applications.
PHP
If your application needs offline access to a Google API, set the API client's access type to offline :
$client->setAccessType("offline");After a user grants offline access to the requested scopes, you can continue to use the API client to access Google APIs on the user's behalf when the user is offline. The client object will refresh the access token as needed.
Python
In Python, set the access_type keyword argument to offline to ensure that you will be able to refresh the access token without having to re-prompt the user for permission. It is very possible that access_type will not be the only keyword argument that you set, as shown in the example below.
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')After a user grants offline access to the requested scopes, you can continue to use the API client to access Google APIs on the user's behalf when the user is offline. The client object will refresh the access token as needed.
Ruby
If your application needs offline access to a Google API, set the API client's access type to offline :
auth_client.update!(
:additional_parameters => {"access_type" => "offline"}
)After a user grants offline access to the requested scopes, you can continue to use the API client to access Google APIs on the user's behalf when the user is offline. The client object will refresh the access token as needed.
HTTP/REST
To refresh an access token, your application sends an HTTPS POST request to Google's authorization server ( https://oauth2.googleapis.com/token ) that includes the following parameters:
| Fields | |
|---|---|
client_id | The client ID obtained from the API Console. |
client_secret | The client secret obtained from the API Console. |
grant_type | As defined in the OAuth 2.0 specification , this field's value must be set to refresh_token . |
refresh_token | The refresh token returned from the authorization code exchange. |
The following snippet shows a sample request:
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
As long as the user has not revoked the access granted to the application, the token server returns a JSON object that contains a new access token. The following snippet shows a sample response:
{
"access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
"expires_in": 3920,
"scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
"token_type": "Bearer"
}Note that there are limits on the number of refresh tokens that will be issued; one limit per client/user combination, and another per user across all clients. You should save refresh tokens in long-term storage and continue to use them as long as they remain valid. If your application requests too many refresh tokens, it may run into these limits, in which case older refresh tokens will stop working.
Revoking a token
In some cases a user may wish to revoke access given to an application. A user can revoke access by visiting Account Settings . See the Remove site or app access section of the Third-party sites & apps with access to your account support document for more information.
It is also possible for an application to programmatically revoke the access given to it. Programmatic revocation is important in instances where a user unsubscribes, removes an application, or the API resources required by an app have significantly changed. In other words, part of the removal process can include an API request to ensure the permissions previously granted to the application are removed.
PHP
To programmatically revoke a token, call revokeToken() :
$client->revokeToken();
Python
To programmatically revoke a token, make a request to https://oauth2.googleapis.com/revoke that includes the token as a parameter and sets the Content-Type header:
requests.post('https://oauth2.googleapis.com/revoke',
params={'token': credentials.token},
headers = {'content-type': 'application/x-www-form-urlencoded'})Ruby
To programmatically revoke a token, make an HTTP request to the oauth2.revoke endpoint:
uri = URI('https://oauth2.googleapis.com/revoke')
response = Net::HTTP.post_form(uri, 'token' => auth_client.access_token)
The token can be an access token or a refresh token. If the token is an access token and it has a corresponding refresh token, the refresh token will also be revoked.
If the revocation is successfully processed, then the status code of the response is 200 . For error conditions, a status code 400 is returned along with an error code.
HTTP/REST
To programmatically revoke a token, your application makes a request to https://oauth2.googleapis.com/revoke and includes the token as a parameter:
curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
https://oauth2.googleapis.com/revoke?token={token}The token can be an access token or a refresh token. If the token is an access token and it has a corresponding refresh token, the refresh token will also be revoked.
If the revocation is successfully processed, then the HTTP status code of the response is 200 . For error conditions, an HTTP status code 400 is returned along with an error code.