OAuth 2.0 pour mobiles et applications de bureau

<ph type="x-smartling> La vue d'ensemble récapitule les flux OAuth 2.0 acceptés par Google, qui peuvent vous aider à vous assurer que vous avez sélectionné le bon flux pour votre application.

Ce document explique comment les applications installées sur les 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 pour stocker des fichiers dans leurs Drive.

Les applications installées sont distribuées sur des appareils individuels. Nous partons du principe que ces applications ne peuvent pas garder de secrets. Ils peuvent accéder aux API Google lorsque l'utilisateur est présent dans l'application ou lorsqu'elle 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 locale 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 Google Sign-In gèrent l'authentification et l'autorisation des utilisateurs, et peuvent être plus simples à mettre en œuvre que le protocole de niveau inférieur décrit ici.

Pour les applications fonctionnant sur des appareils non compatibles avec un navigateur système ou avec des fonctionnalités de saisie limitées, telles que des téléviseurs, des consoles de jeu, des caméras ou des imprimantes, consultez la section OAuth 2.0 pour les téléviseurs et les appareils ou Se connecter sur des téléviseurs et des appareils de saisie limités.

Bibliothèques et exemples

Nous vous recommandons d'utiliser les bibliothèques et exemples suivants pour vous aider à mettre en œuvre le parcours OAuth 2.0 décrit dans ce document:

Prerequisites

Activer les API pour votre projet.

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

Pour activer une API pour votre projet:

  1. Open the API Library dans Google API Console.
  2. If prompted, select a project, or create a new one.
  3. API Library répertorie toutes les API disponibles, regroupées par famille de produits et classées en fonction de leur popularité. Si l'API que vous souhaitez activer n'est pas visible dans la liste, recherchez-la ou cliquez sur Tout afficher dans la famille de produits à laquelle elle appartient.
  4. Sélectionnez l'API que vous souhaitez activer, puis cliquez sur le bouton Activer.
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

Créer des identifiants d'autorisation

Toute application qui utilise OAuth 2.0 pour accéder aux API Google doit disposer d'identifiants d'autorisation qui identifient l'application 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.

  1. Go to the Credentials page.
  2. Cliquez sur Créer des identifiants > ID client OAuth.
  3. Les sections ci-dessous décrivent les types de clients et les méthodes de redirection acceptés par 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)

Un schéma d'URI personnalisé est recommandé pour les applications Android, iOS et Universal Windows Platform (UWP).

Android
  1. Sélectionnez le type d'application Android.
  2. Saisissez le nom du client OAuth. Ce nom est affiché sur votre projet Credentials page pour identifier le client.
  3. Saisissez le nom de package de votre application Android. Cette valeur est définie dans l'attribut package de l'élément <manifest> dans le fichier manifeste de votre application.
  4. Saisissez l'empreinte du certificat de signature SHA-1 de la distribution de l'application.
    • Si votre application utilise la signature d'application par Google Play, copiez l'empreinte SHA-1 sur la page de signature d'application de la Play Console.
    • Si vous gérez votre propre keystore et clés de signature, utilisez l'utilitaire keytool inclus avec Java pour imprimer les informations de certificat dans un format lisible. Copiez la valeur SHA1 dans la section Certificate fingerprints du résultat keytool. Pour en savoir plus, consultez la section Authentifier votre client de la documentation sur les API Google pour Android.
  5. Cliquez sur Create (Créer).
iOS
  1. Sélectionnez le type d'application iOS.
  2. Saisissez le nom du client OAuth. Ce nom est affiché sur votre projet Credentials page pour identifier le client.
  3. Saisissez l'identifiant du bundle pour votre application. L'ID du bundle correspond à la valeur de la clé CFBundleIdentifier du fichier de ressources de la liste d'informations de l'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 du bundle s'affiche également dans la section "General Information" (Informations générales) de la page "Informations sur l'application" de l'application sur le site App Store d'Apple.
  4. (Facultatif)

    Saisissez l'ID de l'App Store d'Apple si l'application est publiée sur l'App Store d'Apple. L'ID de magasin est une chaîne numérique incluse dans l'URL de l'App Store d'Apple.

    1. Ouvrez l'application App Store d'Apple sur votre appareil iOS ou iPadOS.
    2. Recherchez votre application.
    3. Sélectionnez le bouton "Partager" (symbole carré et flèche vers le haut).
    4. Sélectionnez Copier le lien.
    5. 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

  5. (Facultatif)

    Saisissez votre ID d'équipe. Pour en savoir plus, consultez la section Trouver votre ID d'équipe dans la documentation de votre compte de développeur Apple.

  6. Cliquez sur Create (Créer).
UWP
  1. Sélectionnez le type d'application Universal Windows Platform.
  2. Saisissez le nom du client OAuth. Ce nom est affiché sur votre projet Credentials page pour identifier le client.
  3. Saisissez l'identifiant Microsoft Store de 12 caractères de votre application. Vous trouverez cette valeur dans le Centre des partenaires Microsoft sur la page Identité de l'application de la section "Gestion des applications".
  4. Cliquez sur Create (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, bureau Windows)

Pour recevoir le code d'autorisation à l'aide de cette URL, votre application doit écouter sur le serveur Web local. Cela est possible sur de nombreuses plates-formes, mais pas pour toutes. Toutefois, si votre plate-forme le permet, c'est le mécanisme recommandé pour obtenir le code d'autorisation.

Lorsque votre application reçoit la réponse d'autorisation, elle doit y répondre en affichant une page HTML qui indique à l'utilisateur de fermer le navigateur et d'y revenir.

Utilisation recommandée Applications macOS, Linux et Windows (mais pas Windows Platform)
Valeurs des formulaires 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 l'accès aux ressources dont elle a besoin tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils peuvent accorder à votre application. Par conséquent, il peut y avoir une relation inverse entre le nombre de champs d'application demandés et la probabilité d'obtenir le consentement de l'utilisateur.

Avant de commencer à mettre en œuvre l'autorisation OAuth 2.0, nous vous recommandons d'identifier les niveaux d'accès requis pour votre application.

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

Obtenir des jetons d'accès OAuth 2.0

La procédure suivante montre comment votre application interagit avec le serveur OAuth 2.0 de Google pour obtenir le consentement d'un utilisateur afin d'exécuter une requête API pour le compte de l'utilisateur. Votre application doit disposer de ce consentement pour pouvoir exécuter une requête API Google nécessitant une autorisation utilisateur.

Étape 1: Générer un outil de vérification de code et lancer un défi

Google accepte le protocole Argumentaire pour l'échange de code (PKCE) pour renforcer la sécurité du flux d'application installé. Un outil de vérification de code unique est créé pour chaque requête d'autorisation. Sa valeur transformée, appelée "code_challenge", est envoyée au serveur d'autorisation afin d'obtenir le code d'autorisation.

Créer l'outil de vérification de code

code_verifier est une chaîne aléatoire à entropie élevée utilisant les caractères non réservés [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" d'une longueur minimale de 43 caractères et 8 caractères maximum

L'outil de vérification de code doit disposer d'une entropie suffisante pour qu'il soit difficile à deviner.

Créer le défi du code

Deux méthodes de création de défi de code sont acceptées.

Méthodes de génération de défis pour le code
S256 (recommandé) Le défi du code est le hachage SHA256 encodé de base64URL (sans remplissage) de l'outil de vérification de code.
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
plain La question d'authentification à l'aide de code est identique à celle de l'outil de vérification de code généré ci-dessus.
code_challenge = code_verifier

Étape 2: Envoyez une requête au serveur OAuth 2.0 de Google

Pour obtenir l'autorisation de l'utilisateur, envoyez une demande 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 des sessions, authentifie l'utilisateur et obtient le consentement de l'utilisateur. Le point de terminaison n'est accessible que via SSL et refuse les connexions HTTP (non SSL).

Le serveur d'autorisation est compatible avec 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 pouvez trouver cette valeur dans le API ConsoleCredentials page.

redirect_uri Obligatoire

Détermine la façon dont 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 tenant compte d'une méthode de redirection spécifique.

La valeur doit correspondre exactement à l'un des URI de redirection autorisés pour le client OAuth 2.0, que vous avez configurés dans API ConsoleCredentials page. Si cette valeur ne correspond pas à un URI autorisé, vous obtenez une erreur redirect_uri_mismatch.

Le tableau ci-dessous indique la valeur du paramètre redirect_uri appropriée pour chaque méthode:

Valeurs redirect_uri
Schéma d'URI personnalisé com.example.app:redirect_uri_path

ou

com.googleusercontent.apps.123:redirect_uri_path
  • com.example.app est la notation DNS inverse d'un domaine que vous contrôlez. Le schéma personnalisé doit contenir un point pour être valide.
  • com.googleusercontent.apps.123 correspond à la notation DNS inverse de l'ID client.
  • redirect_uri_path est un composant de chemin facultatif, tel que /oauth2redirect. Notez que le chemin d'accès doit commencer par une seule barre oblique, différente des URL HTTP standards.
Adresse IP de rebouclage http://127.0.0.1:port ou http://[::1]:port

Interrogez votre plate-forme pour obtenir l'adresse IP de rebouclage appropriée et démarrez un écouteur HTTP sur un port disponible aléatoire. Remplacez port par le numéro de port réel auquel votre application écoute.

response_type Obligatoire

Détermine si le point de terminaison Google OAuth 2.0 renvoie un code d'autorisation.

Définissez la valeur du paramètre sur code pour les applications installées.

scope Obligatoire

Liste de champs d'application délimitée par des espaces qui identifient les ressources auxquelles votre application peut accéder au nom de l'utilisateur. Ces valeurs indiquent l'écran de consentement que Google affiche à l'utilisateur.

Les champs d'application permettent à votre application de demander l'accès aux ressources dont elle a besoin tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils peuvent accorder à votre application. Par conséquent, il existe une relation inverse entre le nombre de champs d'application demandés et la probabilité d'obtenir le consentement de l'utilisateur.

code_challenge Approche conseillée

Spécifie un code_verifier encodé qui sera utilisé comme question côté serveur lors de l'échange du code d'autorisation. Consultez la section Créer un défi de code ci-dessus pour plus d'informations.

code_challenge_method Approche conseillée

Spécifie la méthode utilisée pour encoder un code_verifier qui sera utilisé lors de l'échange du code d'autorisation. Il doit être utilisé avec le paramètre code_challenge décrit ci-dessus. La valeur du champ code_challenge_method est définie par défaut sur plain si elle n'est pas présente dans la requête qui inclut un code_challenge. Les seules valeurs acceptées pour ce paramètre sont S256 ou plain.

state Approche conseillée

Spécifie toute valeur de chaîne que votre application utilise pour maintenir l'état entre votre requête d'autorisation et la réponse du serveur d'autorisation. Le serveur renvoie la valeur exacte que vous envoyez sous forme de paire name=value dans l'identifiant de fragment d'URL (#) de redirect_uri, après que l'utilisateur a autorisé ou refusé la demande d'accès de votre application.

Vous pouvez utiliser ce paramètre à diverses fins, par exemple pour rediriger l'utilisateur vers la ressource appropriée de votre application, pour envoyer des nonces et pour atténuer la falsification de requêtes intersites. Étant donné que la valeur redirect_uri peut être devinée, l'utilisation d'une valeur state peut renforcer l'assurance qu'une connexion entrante est le résultat d'une requête d'authentification. Si vous générez une chaîne aléatoire ou encodez le hachage d'un cookie ou d'une autre valeur qui capture l'état du client, vous pouvez valider la réponse pour vous assurer que la requête et la réponse proviennent du même navigateur, ce qui offre une protection contre les attaques telles que la falsification de requêtes intersites. Consultez la documentation d'OpenID Connect pour découvrir comment créer et confirmer un jeton state.

login_hint Facultatif

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

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

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 state facultatif. Chaque URL contient des sauts de ligne et des espaces pour les rendre plus lisibles.

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 l'autorisation à l'utilisateur

Dans cette étape, l'utilisateur décide d'accorder ou non l'accès à votre application. À ce stade, Google affiche une fenêtre de consentement indiquant le nom de votre application et les services d'API Google auxquels elle demande l'autorisation d'accéder avec les identifiants d'autorisation de l'utilisateur, ainsi qu'un résumé des champs d'application à accorder. L'utilisateur peut ensuite accepter d'accorder l'accès à un ou plusieurs niveaux d'accès demandés par votre application ou refuser la demande.

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

Erreurs

Les requêtes envoyées au point de terminaison d'autorisation OAuth 2.0 de Google peuvent afficher des messages d'erreur visibles par les utilisateurs au lieu des flux d'authentification et d'autorisation attendus. Les codes d'erreur courants et les solutions suggérées sont répertoriés ci-dessous.

admin_policy_enforced

Le compte Google ne peut pas autoriser un ou plusieurs niveaux d'accès demandés en raison des règles de leur administrateur Google Workspace. Pour savoir comment un administrateur peut restreindre l'accès à tous les champs d'application ou les niveaux d'accès sensibles et restreints jusqu'à ce que l'accès soit explicitement accordé à votre ID client OAuth, consultez l'article d'aide destiné aux administrateurs Google Workspace Contrôler les applications tierces et les données internes ayant accès aux données Google Workspace.

disallowed_useragent

Le point de terminaison de l'autorisation est affiché dans un user-agent intégré interdit par les règles OAuth 2.0 de Google.

Android

Les développeurs Android peuvent rencontrer ce message d'erreur lorsqu'ils ouvrent des demandes d'autorisation dans android.webkit.WebView. Les développeurs doivent utiliser des bibliothèques Android telles que Google Sign-In pour Android ou OpenID Foundation pour AppAuth pour Android.

Les développeurs Web peuvent rencontrer cette erreur lorsqu'une application Android ouvre un lien Web général dans un user-agent intégré et qu'un utilisateur accède au point de terminaison d'autorisation OAuth 2.0 de Google à partir de votre site. Les développeurs doivent autoriser l'ouverture des liens généraux dans le gestionnaire de liens par défaut du système d'exploitation, qui inclut à la fois les gestionnaires Android App Links et l'application par défaut du navigateur. La bibliothèque Android Custom Tabs est également disponible.

iOS

Les développeurs iOS et macOS peuvent rencontrer cette erreur lors de l'ouverture des demandes d'autorisation dans WKWebView. Les développeurs doivent utiliser des bibliothèques iOS comme Google Sign-In pour iOS ou OpenID Foundation pour AppAuth pour iOS.

Les développeurs Web peuvent rencontrer cette erreur lorsqu'une application iOS ou macOS ouvre un lien Web général dans un user-agent intégré, et que l'utilisateur accède au point de terminaison d'autorisation OAuth 2.0 de Google à partir de votre site. Les développeurs doivent autoriser l'ouverture des liens généraux dans le gestionnaire de liens par défaut du système d'exploitation, qui comprend à la fois les gestionnaires Universal Links et l'application de navigateur par défaut. La bibliothèque SFSafariViewController est également une option compatible.

org_internal

L'ID client OAuth dans la requête fait partie d'un projet limitant l'accès aux comptes Google dans une organisation Google Cloud spécifique. Pour en savoir plus sur cette option de configuration, consultez la section Type d'utilisateur de la page "Configurer votre autorisation OAuth"

redirect_uri_mismatch

Le redirect_uri transmis dans la requête d'autorisation ne correspond pas à un URI de redirection autorisé pour l'ID client OAuth. Examinez les URI de redirection autorisés dans Google API Console Credentials page.

La valeur redirect_uri transmise peut être incorrecte pour le type de client.

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

La façon 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 des codes que vous avez créé à l'étape 1
grant_type Comme indiqué dans la spécification OAuth 2.0, la valeur de ce champ doit être définie sur authorization_code.
redirect_uri Un des URI de redirection répertoriés pour votre projet dans le API ConsoleCredentials page pour le client_id donné.

L'extrait de code suivant présente un exemple de requête:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=http%3A//127.0.0.1%3A9004&
grant_type=authorization_code

Pour répondre à cette requête, Google renvoie un objet JSON contenant un jeton d'accès de courte durée et un jeton d'actualisation.

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 sur 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 Champs d'application d'accès accordés par access_token, exprimés sous forme de liste sensible à la casse.
token_type Type de jeton renvoyé. Pour l'instant, la valeur de ce champ est toujours définie sur Bearer.

L'extrait de code suivant illustre un exemple de réponse:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

Appeler des API Google

Une fois que votre application a obtenu un jeton d'accès, vous pouvez l'utiliser pour appeler des API Google au nom d'un compte utilisateur donné, si le ou les niveaux d'accès requis par l'API vous ont été accordés. Pour ce faire, incluez le jeton d'accès dans une requête adressée à l'API en incluant un paramètre de requête access_token ou une valeur d'en-tête HTTP Authorization Bearer. Dans la mesure du possible, il est préférable d'utiliser l'en-tête HTTP, car les chaînes de requête sont généralement visibles dans les journaux du serveur. Dans la plupart des cas, vous pouvez utiliser une bibliothèque cliente pour configurer vos appels aux API Google (par exemple, lorsque vous appelez l'API Drive Files).

Vous pouvez essayer toutes les API Google et en consulter la portée sur OAuth 2.0 Playground.

Exemples de requêtes HTTP GET

Un appel vers le point de terminaison drive.files (API Drive Files) à l'aide de l'en-tête HTTP Authorization: Bearer peut se présenter comme suit. Notez que vous devez spécifier votre propre jeton d'accès:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

Voici un appel vers la même API pour l'utilisateur authentifié à l'aide du paramètre de chaîne de requête access_token:

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

Exemples curl

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

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

Vous pouvez également sélectionner l'option du paramètre de chaîne de requête:

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

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 n'est pas présent) si vous avez demandé l'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 POSTau serveur d'autorisation Google (https://oauth2.googleapis.com/token) qui inclut les paramètres suivants:

Champs
client_id ID client obtenu à partir de API Console.
client_secret Code secret du client obtenu à partir de API Console. (Le champ client_secret ne s'applique pas aux requêtes des 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 du code d'autorisation.

L'extrait de code suivant présente un exemple de requête:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

Tant que l'utilisateur n'a pas révoqué l'accès accordé à l'application, le serveur de jetons renvoie un objet JSON contenant un nouveau jeton. L'extrait de code suivant présente un exemple de réponse:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "token_type": "Bearer"
}

Notez que le nombre de jetons d'actualisation émis sera limité : une limite par combinaison client/utilisateur et une autre par utilisateur pour tous les clients. Nous vous recommandons d'enregistrer les jetons d'actualisation dans un espace de stockage à long terme et de les utiliser tant qu'ils restent valides. Si votre application demande trop de jetons d'actualisation, elle peut atteindre ces limites. Dans ce cas, les anciens jetons d'actualisation ne fonctionnent plus.

Révoquer un jeton

Dans certains cas, l'utilisateur peut souhaiter révoquer l'accès accordé à une application. Un utilisateur peut révoquer l'accès dans les paramètres du compte. Pour en savoir plus, consultez la section Supprimer l'accès aux sites et aux applications depuis le site et les applications tiers ayant accès à votre compte.

Il est également possible pour une application de révoquer par programmation l'accès qui lui est accordé. La révocation programmatique est importante dans les cas où un utilisateur se désabonne, supprime une application ou les ressources d'API requises par une application ont changé de manière significative. En d'autres termes, une partie du processus de suppression peut inclure une requête API pour garantir la suppression des autorisations précédemment accordées à l'application.

Pour révoquer automatiquement un jeton, votre application envoie une requête à https://oauth2.googleapis.com/revoke et inclut ce jeton en tant que paramètre:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

Le jeton peut être un jeton d'accès ou un jeton d'actualisation. Si le jeton est un jeton d'accès et qu'il possède un jeton d'actualisation correspondant, il est également révoqué.

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

Documentation complémentaire

Les bonnes pratiques OAuth 2.0 pour les applications natives établissent un grand nombre des bonnes pratiques décrites ici.