Ce document explique comment les applications installées sur des appareils tels que les téléphones, les tablettes et les ordinateurs utilisent les points de terminaison OAuth 2.0 de Google pour autoriser l'accès aux API Google.
OAuth 2.0 permet aux utilisateurs de partager des données spécifiques avec une application tout en préservant la confidentialité de leurs noms d'utilisateur, mots de passe et autres informations. Par exemple, une application peut utiliser OAuth 2.0 pour obtenir l'autorisation des utilisateurs à stocker des fichiers dans Google Drive.
Les applications installées sont distribuées sur des appareils individuels. Nous partons du principe qu'elles ne peuvent pas conserver de secrets. Ils peuvent accéder aux API Google lorsque l'utilisateur est présent dans l'application ou lorsque celle-ci s'exécute en arrière-plan.
Ce flux d'autorisation est semblable à celui utilisé pour les applications de serveur Web. La principale différence est que les applications installées doivent ouvrir le navigateur système et fournir un URI de redirection local pour gérer les réponses du serveur d'autorisation de Google.
Alternatives
Pour les applications mobiles, vous pouvez utiliser Google Sign-In pour Android ou iOS. Les bibliothèques clientes de Google Sign-In traitent l'authentification et l'autorisation des utilisateurs. Elles peuvent être plus simples à mettre en œuvre que le protocole de niveau inférieur décrit ici.
Pour les applications exécutées sur des appareils qui ne sont pas compatibles avec un navigateur système ou dont les fonctionnalités d'entrée sont limitées, comme les téléviseurs, les consoles de jeu, les appareils photo ou les imprimantes, consultez OAuth 2.0 pour les téléviseurs et appareils ou Connexion sur les téléviseurs et les périphériques d'entrée limités.
Bibliothèques et exemples
Nous vous recommandons les bibliothèques et exemples suivants pour vous aider à implémenter le flux OAuth 2.0 décrit dans ce document:
- Bibliothèque AppAuth pour Android
- Bibliothèque AppAuth pour iOS
- OAuth pour les applications: exemples Windows
Prérequis
Activer les API pour votre projet.
Toute application qui appelle des API Google doit activer ces API dans API Console.
Pour activer une API pour votre projet:
- Open the API Library dans Google API Console.
- If prompted, select a project, or create a new one.
- API Library liste toutes les API disponibles, regroupées par famille de produits et par popularité. Si l'API que vous souhaitez activer ne figure pas dans la liste, recherchez-la ou cliquez sur Tout afficher dans la famille de produits à laquelle elle appartient.
- Sélectionnez l'API que vous souhaitez activer, puis cliquez sur le bouton Activer.
- If prompted, enable billing.
- If prompted, read and accept the API's Terms of Service.
Créer des identifiants d'autorisation
Toute application qui accède aux API Google via OAuth 2.0 doit disposer d'identifiants d'autorisation qui l'identifient sur le serveur OAuth 2.0 de Google. Les étapes suivantes expliquent comment créer des identifiants pour votre projet. Vos applications peuvent ensuite utiliser les identifiants pour accéder aux API que vous avez activées pour ce projet.
- Go to the Credentials page.
- Cliquez sur Créer des identifiants > ID client OAuth.
- Les sections ci-dessous décrivent les types de clients et les méthodes de redirection compatibles avec le serveur d'autorisation de Google. Choisissez le type de client recommandé pour votre application, nommez votre client OAuth, puis définissez les autres champs du formulaire de manière appropriée.
Schéma d'URI personnalisé (Android, iOS, UWP)
Nous vous recommandons d'utiliser un schéma d'URI personnalisé pour les applications Android et iOS, ainsi que pour les applications Universal Windows Platform (UWP).
Android
- Sélectionnez le type d'application Android.
- Saisissez un nom pour le client OAuth. Ce nom est affiché sur le fichier Credentials page de votre projet afin d'identifier le client.
- Saisissez le nom de package de votre application Android. Cette valeur est définie dans l'
attribut
package
de l'élément<manifest>
du fichier manifeste de votre application. - Saisissez l'empreinte du certificat de signature SHA-1 de la distribution de l'application.
- Si votre application utilise la signature d'application Google Play, copiez l'empreinte SHA-1 de la page de signature d'application de la Play Console.
- Si vous gérez votre propre magasin de clés et vos propres clés de signature, utilisez l'utilitaire keytool fourni avec Java pour imprimer les informations du certificat dans un format plus lisible. Copiez la valeur
SHA1
dans la sectionCertificate fingerprints
du résultat keytool. Pour en savoir plus, consultez Authentifier votre client dans la documentation des API Google pour Android.
- Cliquez sur Créer.
iOS
- Sélectionnez le type d'application iOS.
- Saisissez un nom pour le client OAuth. Ce nom est affiché sur le fichier Credentials page de votre projet afin d'identifier le client.
- Saisissez l'identifiant de groupe de votre application. Il s'agit de la valeur de la clé CFBundleIdentifier qui figure dans le fichier de ressources de liste de propriétés d'information de votre application (info.plist). La valeur s'affiche le plus souvent dans le volet "Général" ou dans le volet "Signature et fonctionnalités" de l'éditeur de projet Xcode. L'ID de bundle est également affiché dans la section "Informations générales" de la page "Informations sur l'application" de l'application sur le site App Store d'Apple.
- (Facultatif)
Saisissez l'ID App Store de votre application si celle-ci est publiée sur l'App Store d'Apple. L'ID de magasin est une chaîne numérique incluse dans chaque URL Apple App Store.
- Ouvrez l'application App Store d'Apple sur votre appareil iOS ou iPadOS.
- Recherchez votre application.
- Sélectionnez le bouton "Partager" (carré et symbole haut).
- Sélectionnez Copier le lien.
- Collez le lien dans un éditeur de texte. L'ID App Store est la dernière partie de l'URL.
Exemple :
https://apps.apple.com/app/google/id284815942
- (Facultatif)
Saisissez votre ID d'équipe. Pour en savoir plus, consultez la section Localiser votre ID d'équipe dans la documentation du compte de développeur Apple.
- Cliquez sur Créer.
UWP
- Sélectionnez le type d'application Plate-forme Windows universelle.
- Saisissez un nom pour le client OAuth. Ce nom est affiché sur le fichier Credentials page de votre projet afin d'identifier le client.
- Saisissez l'ID Microsoft Store de votre application à 12 caractères. Vous trouverez cette valeur dans le Centre des partenaires Microsoft, sur la page Identité de l'application de la section "Gestion des applications".
- Cliquez sur Créer.
Pour les applications UWP, le schéma d'URI personnalisé ne peut pas dépasser 39 caractères.
Adresse IP de rebouclage (macOS, Linux, ordinateur de bureau Windows)
Pour recevoir le code d'autorisation à l'aide de cette URL, votre application doit écouter sur le serveur Web local. C'est possible sur de nombreuses plates-formes, mais pas toutes. Toutefois, si votre plate-forme le permet, il s'agit du mécanisme recommandé pour obtenir le code d'autorisation.
Lorsque votre application reçoit la réponse d'autorisation, elle doit répondre en affichant une page HTML qui demande à l'utilisateur de fermer le navigateur et de revenir à votre application pour une meilleure facilité d'utilisation.
Utilisation recommandée | Applications de bureau macOS, Linux et Windows (mais pas la plate-forme Windows universelle) |
Valeurs de formulaire | Définissez le type d'application sur Application de bureau. |
Copier-coller manuel
Identifier les niveaux d'accès
Les champs d'application permettent à votre application de demander uniquement l'accès aux ressources dont elle a besoin, tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils accordent à votre application. Ainsi, il peut y avoir une relation inverse entre le nombre de champs d'application demandés et la probabilité d'obtenir le consentement de l'utilisateur.
Avant de commencer à implémenter l'autorisation OAuth 2.0, nous vous recommandons d'identifier les champs d'application pour lesquels votre application aura besoin d'une autorisation d'accès.
Le document Champs d'application de l'API OAuth 2.0 contient la liste complète des champs d'application que vous pouvez utiliser pour accéder aux API Google.
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 afin d'exécuter une requête API en son nom. Votre application doit disposer de ce consentement pour pouvoir exécuter une requête API Google nécessitant l'autorisation de l'utilisateur.
Étape 1: Générer un outil de vérification du code et lancer un défi
Google accepte le protocole PKCE (Proof Key for Code Exchange) pour renforcer la sécurité du flux d'application installé. Un vérificateur de code unique est créé pour chaque requête d'autorisation, et sa valeur transformée, appelée "code_challenge", est envoyée au serveur d'autorisation pour obtenir le code d'autorisation.
Créer l'outil de vérification de code
Un code_verifier
est une chaîne aléatoire d'entropie élevée à l'aide des caractères non réservés [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~", d'une longueur minimale de 43 caractères et d'une longueur maximale de 128 caractères.
L'entropie doit être suffisante pour que l'outil de vérification du code ne permette pas de deviner la valeur.
Créer le défi Code
Deux méthodes de création du défi de code sont acceptées.
Méthodes de génération des défis de code | |
---|---|
S256 (recommandé) | Le défi de code est le hachage SHA256 encodé en base64URL (sans remplissage) de l'outil de vérification de code.
|
plain | L'authentification via le code est identique à celle de l'outil de vérification de code généré ci-dessus.
|
Étape 2: Envoyez une requête au serveur OAuth 2.0 de Google
Pour obtenir l'autorisation de l'utilisateur, envoyez une requête au serveur d'autorisation de Google à l'adresse https://accounts.google.com/o/oauth2/v2/auth
. Ce point de terminaison gère la recherche active de la session, authentifie l'utilisateur et obtient le consentement de l'utilisateur. Le point de terminaison n'est accessible que via SSL. Il refuse les connexions HTTP (non SSL).
Le serveur d'autorisation accepte les paramètres de chaîne de requête suivants pour les applications installées:
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 comment le serveur d'autorisation de Google envoie une réponse à votre application. Plusieurs options de redirection sont disponibles pour les applications installées, et vous avez configuré vos identifiants d'autorisation en pensant à une méthode de redirection particulière. 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 fichier API Console
Credentials pagede votre client. Si cette valeur ne correspond pas à un URI autorisé, vous obtenez une erreur Le tableau ci-dessous indique la valeur du paramètre
|
||||||
response_type |
Obligatoire
Détermine si le point de terminaison Google OAuth 2.0 renvoie un code d'autorisation. Définissez la valeur du paramètre sur |
||||||
scope |
Obligatoire
Liste de champs d'application, séparés par des espaces, qui identifient les ressources auxquelles votre application peut accéder au nom de l'utilisateur. Ces valeurs indiquent à l'écran d'autorisation que Google affiche à l'utilisateur. Les champs d'application permettent à votre application de demander uniquement l'accès aux ressources dont elle a besoin, tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils accordent à votre application. Ainsi, il existe une relation inverse entre le nombre de champs d'application demandés et la probabilité d'obtention du consentement de l'utilisateur. |
||||||
code_challenge |
Approche conseillée
Spécifie un |
||||||
code_challenge_method |
Approche conseillée
Spécifie la méthode utilisée pour encoder un |
||||||
state |
Approche conseillée
Spécifie une valeur de chaîne que votre application utilise pour conserver l'état entre votre requête d'autorisation et la réponse du serveur d'autorisation.
Une fois que l'utilisateur a accepté ou refusé la demande d'accès, votre serveur renvoie la valeur exacte que vous envoyez en tant que paire Vous pouvez utiliser ce paramètre à différentes fins, par exemple pour rediriger l'utilisateur vers la ressource appropriée de votre application, pour envoyer des nonces et pour atténuer les contrefaçons de requêtes intersites. Étant donné que votre |
||||||
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 de Google. Cet indice permet au serveur de simplifier le processus de connexion en préremplissant le champ d'adresse e-mail dans le formulaire de connexion ou en sélectionnant la session multiconnexion appropriée. Définissez la valeur du paramètre sur une adresse e-mail ou un identifiant |
Exemples d'URL d'autorisation
Les onglets ci-dessous présentent des exemples d'URL d'autorisation pour les différentes options d'URI de redirection.
Les URL sont identiques, à l'exception de la valeur du paramètre redirect_uri
. Les URL contiennent également les paramètres response_type
et client_id
requis, ainsi que le paramètre facultatif state
. Chaque URL contient des sauts de ligne et des espaces pour une meilleure lisibilité.
Schéma d'URI personnalisé
https://accounts.google.com/o/oauth2/v2/auth? scope=& response_type=code& state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken& redirect_uri=com.example.app%3A/oauth2redirect& client_id=client_id
Adresse IP de rebouclage
https://accounts.google.com/o/oauth2/v2/auth? scope=& response_type=code& state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken& redirect_uri=http%3A//127.0.0.1%3A9004& client_id=client_id
Étape 3: Google demande le consentement de l'utilisateur
Lors de cette étape, l'utilisateur décide s'il faut accorder l'accès demandé à votre application. À ce stade, Google affiche une fenêtre de consentement indiquant le nom de votre application et les services d'API Google pour lesquels elle demande une autorisation d'accès avec les identifiants d'autorisation de l'utilisateur et un résumé des champs d'application à accorder. L'utilisateur peut ensuite autoriser l'accès à un ou plusieurs champs d'application demandés par votre application, ou refuser la demande.
À ce stade, votre application n'a rien à faire. Elle attend la réponse du serveur OAuth 2.0 de Google pour indiquer si un accès a été accordé. Cette réponse est expliquée à l'étape suivante.
Erreurs
Les requêtes envoyées au point de terminaison d'autorisation OAuth 2.0 de Google peuvent afficher des messages d'erreur destinés aux utilisateurs au lieu des flux d'authentification et d'autorisation attendus. Vous trouverez ci-dessous la liste des codes d'erreur courants et des suggestions de résolution.
admin_policy_enforced
Le compte Google ne peut pas autoriser un ou plusieurs champs d'application demandés en raison des règles définies par son administrateur Google Workspace. Consultez l'article d'aide pour les administrateurs Google Workspace Contrôler les applications tierces et internes qui accèdent aux données Google Workspace pour savoir comment un administrateur peut restreindre l'accès à tous les champs d'application ou aux champs d'application sensibles et restreints jusqu'à ce que l'accès soit explicitement accordé à votre ID client OAuth.
disallowed_useragent
Le point de terminaison de l'autorisation est affiché dans un user-agent intégré non autorisé par les Règles OAuth 2.0 de Google.
Android
Les développeurs Android peuvent rencontrer ce message d'erreur lorsqu'ils ouvrent des requêtes d'autorisation dans android.webkit.WebView
.
Les développeurs doivent plutôt utiliser des bibliothèques Android telles que Google Sign-In pour Android ou AppAuth pour Android de l'OpenID Foundation.
Les développeurs Web peuvent rencontrer cette erreur lorsqu'une application Android ouvre un lien Web général dans un user-agent intégré et qu'un utilisateur accède au point de terminaison d'autorisation OAuth 2.0 de Google depuis votre site. Les développeurs doivent autoriser l'ouverture des liens généraux dans le gestionnaire de liens par défaut du système d'exploitation, qui inclut à la fois les gestionnaires Android App Links ou l'application de navigateur par défaut. La bibliothèque Android Custom Tabs est également disponible.
iOS
Les développeurs iOS et macOS peuvent rencontrer cette erreur lors de l'ouverture des requêtes d'autorisation dans WKWebView
.
Les développeurs doivent plutôt utiliser des bibliothèques iOS telles que Google Sign-In pour iOS ou AppAuth pour iOS de l'OpenID Foundation.
Les développeurs Web peuvent rencontrer cette erreur lorsqu'une application iOS ou macOS ouvre un lien Web général dans un user-agent intégré et qu'un utilisateur accède au point de terminaison d'autorisation OAuth 2.0 de Google depuis votre site. Les développeurs doivent autoriser l'ouverture des liens généraux dans le gestionnaire de liens par défaut du système d'exploitation, qui inclut à la fois les gestionnaires Universal Links ou l'application de navigateur par défaut. La bibliothèque SFSafariViewController
est également disponible.
org_internal
L'ID client OAuth dans la requête fait partie d'un projet limitant l'accès aux comptes Google dans une organisation Google Cloud spécifique. Pour en savoir plus sur cette option de configuration, consultez la section Type d'utilisateur de l'article d'aide sur la configuration de l'écran d'autorisation OAuth.
invalid_grant
Si vous utilisez un vérificateur de code et un défi, le paramètre code_callenge
n'est pas valide ou est manquant. Assurez-vous que le paramètre code_challenge
est correctement défini.
Lors de l'actualisation d'un jeton d'accès, celui-ci peut avoir expiré ou avoir été invalidé. Authentifiez l'utilisateur et demandez le consentement de l'utilisateur pour obtenir de nouveaux jetons. Si l'erreur persiste, assurez-vous que votre application a été correctement configurée et que vous utilisez les jetons et paramètres corrects dans votre requête. Sinon, le compte utilisateur a peut-être été supprimé ou désactivé.
redirect_uri_mismatch
Le redirect_uri
transmis dans la requête d'autorisation ne correspond à aucun URI de redirection autorisé pour l'ID client OAuth. Examinez les URI de redirection autorisés dans Google API Console Credentials page.
Le redirect_uri
transmis peut ne pas être valide pour le type de client.
Le paramètre redirect_uri
peut faire référence au flux hors bande OAuth (OOB) devenu obsolète et qui n'est plus accepté. Consultez le guide de migration pour mettre à jour votre intégration.
Étape 4: Gérer la réponse du serveur OAuth 2.0
La manière dont votre application reçoit la réponse d'autorisation dépend du schéma d'URI de redirection qu'elle utilise. Quel que soit le schéma, la réponse contient soit un code d'autorisation (code
), soit une erreur (error
). Par exemple, error=access_denied
indique que l'utilisateur a refusé la requête.
Si l'utilisateur accorde l'accès à votre application, vous pouvez échanger le code d'autorisation contre un jeton d'accès et un jeton d'actualisation, comme décrit à l'étape suivante.
Étape 5: Code d'autorisation Exchange pour les jetons d'actualisation et d'accès
Pour échanger un code d'autorisation contre un jeton d'accès, appelez le point de terminaison https://oauth2.googleapis.com/token
et définissez les paramètres suivants:
Champs | |
---|---|
client_id |
ID client obtenu à partir de API Console Credentials page. |
client_secret |
Code secret du client obtenu à partir de API Console Credentials page. |
code |
Code d'autorisation renvoyé par la requête initiale. |
code_verifier |
L'outil de vérification de code que vous avez créé à l'étape 1. |
grant_type |
Conformément à la spécification OAuth 2.0, la valeur de ce champ doit être définie sur authorization_code . |
redirect_uri |
Un des URI de redirection listés pour votre projet dans API Console
Credentials page pour le client_id donné. |
L'extrait 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=http://127.0.0.1:9004& grant_type=authorization_code
Google répond à cette requête en renvoyant un objet JSON contenant un jeton d'accès de courte durée et un jeton d'actualisation.
La réponse contient les champs suivants :
Champs | |
---|---|
access_token |
Jeton que votre application envoie pour autoriser une requête API Google. |
expires_in |
Durée de vie restante du jeton d'accès en secondes. |
id_token |
Remarque:Cette propriété n'est renvoyée que si votre requête inclut un champ d'application d'identité, tel que openid , profile ou email . La valeur est un jeton Web JSON (JWT, JSON Web Token) contenant des informations d'identité signées numériquement à propos de l'utilisateur. |
refresh_token |
Jeton que vous pouvez utiliser pour obtenir un nouveau jeton d'accès. Les jetons d'actualisation sont valides jusqu'à ce que l'utilisateur révoque l'accès. Notez que les jetons d'actualisation sont toujours renvoyés pour les applications installées. |
scope |
Les champs d'application d'accès accordés par access_token sont exprimés sous la forme d'une liste de chaînes délimitées par des espaces. |
token_type |
Type de jeton renvoyé. Pour le moment, la valeur de ce champ est toujours définie sur Bearer . |
L'extrait 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" }
Appeler des API Google
Une fois que votre application a obtenu un jeton d'accès, vous pouvez l'utiliser pour appeler une API Google au nom d'un compte utilisateur donné si les champs d'application requis par l'API ont été accordés. Pour ce faire, incluez le jeton d'accès dans une requête adressée à l'API en incluant un paramètre de requête access_token
ou une valeur Bearer
d'en-tête HTTP Authorization
. Dans la mesure du possible, il est préférable d'utiliser l'en-tête HTTP, car les chaînes de requête ont tendance à être visibles dans les journaux du serveur. Dans la plupart des cas, vous pouvez utiliser une bibliothèque cliente pour configurer vos appels aux API Google (par exemple, lorsque vous appelez l'API Drive Files).
Vous pouvez essayer toutes les API Google et consulter leur champ d'application sur OAuth 2.0 Playground.
Exemples HTTP GET
Un appel vers le point de terminaison
drive.files
(l'API Drive Files) à l'aide de l'en-tête HTTP Authorization: Bearer
peut se présenter comme suit. Notez que vous devez spécifier votre propre jeton d'accès:
GET /drive/v2/files HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
Voici un appel vers la même API pour l'utilisateur authentifié à l'aide du paramètre de chaîne de requête access_token
:
GET https://www.googleapis.com/drive/v2/files?access_token=access_token
Exemples curl
Vous pouvez tester ces commandes avec l'application de ligne de commande curl
. Voici un exemple qui utilise l'option d'en-tête HTTP (recommandée):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files
Vous pouvez également utiliser l'option de paramètre de chaîne de requête:
curl https://www.googleapis.com/drive/v2/files?access_token=access_token
Actualiser un jeton d'accès
Les jetons d'accès expirent régulièrement et deviennent des identifiants non valides pour une requête API associée. Vous pouvez actualiser un jeton d'accès sans demander d'autorisation à l'utilisateur (y compris lorsque l'utilisateur est absent) si vous avez demandé un accès hors connexion aux champs d'application associés au jeton.
Pour actualiser un jeton d'accès, votre application envoie une requête HTTPS POST
au serveur d'autorisation de Google (https://oauth2.googleapis.com/token
) qui inclut les paramètres suivants:
Champs | |
---|---|
client_id |
ID client obtenu à partir de API Console. |
client_secret |
Code secret du client obtenu à partir de API Console.
(Le paramètre client_secret ne s'applique pas aux requêtes provenant de clients enregistrés en tant qu'applications Android, iOS ou Chrome.)
|
grant_type |
Comme indiqué dans la spécification OAuth 2.0, la valeur de ce champ doit être définie sur refresh_token . |
refresh_token |
Jeton d'actualisation renvoyé par l'échange de code d'autorisation. |
L'extrait suivant présente un exemple de requête:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded client_id=your_client_id& client_secret=your_client_secret& refresh_token=refresh_token& grant_type=refresh_token
Tant que l'utilisateur n'a pas révoqué l'accès accordé à l'application, le serveur de jetons renvoie un objet JSON contenant un nouveau jeton d'accès. L'extrait suivant présente un exemple de réponse:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "scope": "https://www.googleapis.com/auth/drive.metadata.readonly", "token_type": "Bearer" }
Notez que le nombre de jetons d'actualisation sera limité : une limite par combinaison client/utilisateur et une autre par utilisateur pour tous les clients. Vous devez enregistrer les jetons d'actualisation dans un espace de stockage à long terme et continuer à les utiliser tant qu'ils restent valides. Si votre application demande un trop grand nombre de jetons d'actualisation, elle peut dépasser ces limites, auquel cas les anciens jetons d'actualisation cesseront de fonctionner.
Révoquer un jeton
Dans certains cas, l'utilisateur peut souhaiter révoquer l'accès accordé à une application. L'utilisateur peut révoquer l'accès dans Paramètres du compte. Pour en savoir plus, consultez la section Supprimer l'accès à une application ou à un site sur les sites et applications tiers ayant accès à votre compte.
Une application peut également révoquer automatiquement l'accès qui lui est accordé. La révocation programmatique est importante dans les cas où un utilisateur se désabonne, supprime une application ou si les ressources d'API requises par une application ont considérablement changé. En d'autres termes, une partie du processus de suppression peut inclure une requête API pour garantir la suppression des autorisations précédemment accordées à l'application.
Pour révoquer automatiquement un jeton, 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}
Le jeton peut être un jeton d'accès ou un jeton d'actualisation. Si le jeton est un jeton d'accès et qu'il possède un jeton d'actualisation correspondant, le jeton d'actualisation sera également révoqué.
Si la révocation a bien été traitée, le code d'état HTTP de la réponse est 200
. Pour les conditions d'erreur, un code d'état HTTP 400
est renvoyé avec un code d'erreur.
Documentation complémentaire
Les bonnes pratiques OAuth 2.0 pour les applications natives d'IETF indiquent les bonnes pratiques présentées sur cette page.