OAuth 2.0 pour les applications mobiles et de bureau

Ce document explique comment les applications installées sur des appareils tels que des téléphones, des tablettes et des 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 de stocker des fichiers dans leurs Google Drives.

Les applications installées sont distribuées sur des appareils individuels et il est supposé que ces applications ne peuvent pas garder de secrets. Ils peuvent accéder aux API Google pendant que l'utilisateur est présent sur l'application ou lorsque l'application s'exécute en arrière-plan.

Ce flux d'autorisation est similaire à celui utilisé pour les applications 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 préférer 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 elles peuvent être plus simples à mettre en œuvre que le protocole de niveau inférieur décrit ici.

Pour les applications en cours d' exécution sur les appareils qui ne prennent pas en charge un navigateur système ou qui ont des capacités limitées d'entrée, tels que les téléviseurs, les consoles de jeux, appareils photo, imprimantes, voir OAuth 2.0 pour les téléviseurs et appareils ou de connexion Google pour les appareils .

Bibliothèques et échantillons

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

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 :

  1. Open the API Library dans le Google API Console.
  2. If prompted, select a project, or create a new one.
  3. Le API Library répertorie toutes les API disponibles, regroupées par famille de produits et de la popularité. Si l'API que vous souhaitez activer n'est pas visible dans la liste, utilisez la recherche pour le trouver, ou cliquez sur Afficher tout dans la famille de produits auquel il appartient.
  4. Sélectionnez l'API que vous souhaitez activer, puis cliquez sur le bouton Activer.
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

Créer des identifiants d'autorisation

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

  1. Go to the Credentials page.
  2. Cliquez sur Créer des informations d' identification> OAuth ID client.
  3. Les sections ci-dessous décrivent les types de clients et les méthodes de redirection pris en charge par le serveur d'autorisation de Google. Choisissez le type de client recommandé pour votre application, nommez votre client OAuth et définissez les autres champs du formulaire comme il convient.

Schéma d'URI personnalisé (Android, iOS, UWP)

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

Android
  1. Sélectionnez le type d'applications Android.
  2. Saisissez un nom pour le client OAuth. Ce nom est affiché sur votre projet de Credentials page pour identifier le client.
  3. Saisissez le nom du package de votre application Android. Cette valeur est définie dans lepackage attribut du <manifest> élément dans votre application fichier manifeste.
  4. Saisissez l'empreinte du certificat de signature SHA-1 de la distribution de l'application.
    • Si votre application utilise d' app signature par Google Play , copier l'empreinte SHA-1 à partir de la page de signature de l' application de la lecture de la console.
    • Si vous gérez vos propres clés de signature et keystore, utilisez l'utilitaire keytool fourni avec Java pour imprimer des informations de certificat dans un format lisible par l' homme. Copiez le SHA1 valeur dans la Certificate fingerprints section de la sortie keytool. Voir Authentifier votre client dans les API Google pour Android documentation pour plus d' informations.
  5. Cliquez sur Créer.
iOS
  1. Sélectionnez le type d'application iOS.
  2. Saisissez un nom pour le client OAuth. Ce nom est affiché sur votre projet de Credentials page pour identifier le client.
  3. Saisissez l'identifiant du groupe pour votre application. L'ID bundle est la valeur du CFBundleIdentifier fichier de ressources de la liste des biens clé dans l' information de votre application (info.plist). La valeur est le plus souvent affichée dans le volet Général ou le volet Signature et capacités de l'éditeur de projet Xcode. L'ID bundle est également affiché dans la section Informations générales de la page Information sur l' appli pour l'application sur l' App Store d'Apple Store Connect site .
  4. (Optionnel)

    Saisissez l'identifiant App Store de votre application si l'application est publiée dans l'App Store d'Apple. L'identifiant du magasin est une chaîne numérique incluse dans chaque 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 (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/id 284815942

  5. (Optionnel)

    Entrez votre identifiant d'équipe. Voir Localisez votre ID d' équipe dans la documentation du compte développeur Apple pour plus d' informations.

  6. Cliquez sur Créer.
UWP
  1. Sélectionnez le type d'application Windows plate - forme universelle.
  2. Saisissez un nom pour le client OAuth. Ce nom est affiché sur votre projet de Credentials page pour identifier le client.
  3. Saisissez l'ID Microsoft Store à 12 caractères de votre application. Vous pouvez trouver cette valeur dans Microsoft Partner Center sur l' identité App page dans la section de gestion App.
  4. 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 bouclage (macOS, Linux, bureau Windows)

Pour recevoir le code d'autorisation à l'aide de cette URL, votre application doit être à l'écoute sur le serveur Web local. C'est possible sur de nombreuses plateformes, mais pas toutes. Cependant, si votre plateforme le supporte, c'est le mécanisme recommandé pour obtenir le code d'autorisation.

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

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 à l' application de bureau.

Copier/coller manuel

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.

L' API OAuth 2.0 Scopes document contient une liste complète des champs que vous pouvez utiliser pour accéder à des API Google.

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.

Étape 1 : générez un vérificateur de code et lancez un défi

Google prend en charge la clé Preuve pour le code d' échange de protocole (PKCe) pour rendre le flux d'application installé plus sécurisé. Un vérificateur de code unique est créé pour chaque demande 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 le vérificateur de code

Un code_verifier est une chaîne aléatoire cryptographique à haute entropie en utilisant les caractères non réservés [AZ] / [az] / [0-9] / "-" "" / / "_" / "~", avec une longueur minimale de 43 caractères et une longueur maximale de 128 caractères.

Le vérificateur de code doit avoir suffisamment d'entropie pour qu'il ne soit pas pratique de deviner la valeur.

Créer le défi du code

Deux méthodes de création du défi de code sont prises en charge.

Méthodes de génération de défi de code
S256 (recommandé) Le défi du code est le hachage SHA256 codé Base64URL (sans remplissage) du vérificateur de code.
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
plaine Le défi de code est la même valeur que le vérificateur de code généré ci-dessus.
code_challenge = code_verifier

Étape 2 : Envoyez une demande au serveur OAuth 2.0 de Google

Pour obtenir l' autorisation de l' utilisateur, envoyer une demande au serveur d'autorisation de Google à https://accounts.google.com/o/oauth2/v2/auth . Ce point de terminaison gère la recherche de session active, authentifie l'utilisateur et obtient le consentement de l'utilisateur. Le point de terminaison n'est accessible que via SSL et il refuse les connexions HTTP (non SSL).

Le serveur d'autorisation prend en charge les paramètres de chaîne de requête suivants pour les applications installées :

Paramètres
client_id Obligatoire

L'ID client de votre application. Vous pouvez trouver cette valeur dans le API ConsoleCredentials page.

redirect_uri Obligatoire

Détermine comment le serveur d'autorisation de Google envoie une réponse à votre application. Il y a plusieurs options de redirection disponibles aux applications installées, et vous avez configuré vos informations d'identification d'autorisation avec une méthode de redirection particulière à l' esprit.

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

Le tableau ci - dessous indique le lieu redirect_uri de valeur de paramètre pour chaque méthode:

redirect_uri valeurs
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 sous votre contrôle. Le schéma personnalisé doit contenir un point pour être valide.
  • com.googleusercontent.apps.123 est la notation DNS inverse de l'ID client.
  • redirect_uri_path est un élément de tracé facultatif, tel que /oauth2redirect . Notez que le chemin doit commencer par une seule barre oblique, ce qui est différent des URL HTTP classiques.
Adresse IP de bouclage http://127.0.0.1: port ou http://[::1]: port

Interrogez votre plate-forme pour l'adresse IP de bouclage appropriée et démarrez un écouteur HTTP sur un port disponible aléatoire. Remplaçant le port avec le numéro de port réel votre application écoute.

Copier/coller manuel urn:ietf:wg:oauth:2.0:oob
Extraction par programmation urn:ietf:wg:oauth:2.0:oob:auto
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 de code pour les applications installées.

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.

code_challenge conseillé

Indique un encodée code_verifier qui sera utilisé comme un défi côté serveur lors de l' échange de code d'autorisation. Ce paramètre doit être utilisé avec le code_challenge paramètre décrit ci - dessus. Voir créer défi de code section ci - dessus pour plus d' informations.

code_challenge_method conseillé

Indique quelle méthode a été utilisée pour coder une code_verifier qui sera utilisé lors de l' échange de code d'autorisation. Ce paramètre doit être utilisé avec le code_challenge paramètre. La valeur des code_challenge_method par défaut plain sinon présent dans la demande qui comprend un code_challenge . Les seules valeurs prises en charge pour ce paramètre sont S256 ou plain .

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 comme name=value paire dans l'identifiant de fragment d'URL ( # ) du redirect_uri après l'utilisateur consent ou refuse la demande d'accès de votre application.

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 redirect_uri peut être deviné, en utilisant un state valeur peut augmenter votre assurance qu'une connexion entrante est le résultat d'une demande d'authentification. Si vous générez une chaîne aléatoire ou encodez le hachage d'un cookie ou une autre valeur qui capture l'état du client, vous pouvez valider la réponse pour vous assurer en outre que la demande et la réponse proviennent du même navigateur, offrant une protection contre les attaques telles que les attaques intersites. demande de contrefaçon. Voir la OpenID Connect documentation pour un exemple de la façon de créer et de confirmer un state jeton.

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.

Réglez la valeur du paramètre à une adresse e - mail ou sub identifiant, ce qui équivaut à Google ID 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 redirect_uri paramètre. Les URL contiennent aussi le nécessaire response_type et client_id paramètres ainsi que l'option state paramètre. Chaque URL contient des sauts de ligne et des espaces pour plus de lisibilité.

Schéma d'URI personnalisé

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 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 bouclage

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 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

Copier coller

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&
 client_id=client_id

Extraction par programmation

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob%3Aauto&
 client_id=client_id

É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. Voir l'article d'aide Administrateur Google Espace de travail de contrôle qui tiers et des applications internes accéder aux données Google espace de travail pour plus d' informations sur la façon dont un administrateur peut restreindre l' accès à toutes les étendues ou les domaines sensibles et restreints jusqu'à ce que l' accès est explicitement accordé à votre ID client OAuth.

disallowed_useragent

Le point final d'autorisation est affiché à l' intérieur d' un agent utilisateur intégré rejeté par Google Politiques OAuth 2.0 .

Android

Les développeurs Android peuvent rencontrer ce message d'erreur lors de l' ouverture des demandes d'autorisation dansandroid.webkit.WebView . Les développeurs doivent plutôt utiliser les bibliothèques Android telles que Google Sign-In pour Android ou de la Fondation OpenID AppAuth pour Android .

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 devraient permettre des liens généraux d'ouvrir dans le gestionnaire de liaison par défaut du système d'exploitation, qui comprend les applications Android Links gestionnaires ou l'application du navigateur par défaut. Les onglets personnalisés Android bibliothèque est également une option prise en charge.

iOS

les développeurs iOS et Mac OS peuvent rencontrer cette erreur lors de l' ouverture des demandes d'autorisation dansWKWebView . Les développeurs doivent utiliser à la place des bibliothèques iOS tels que Google Sign-In pour iOS ou de la Fondation OpenID 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 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 devraient permettre des liens généraux d'ouvrir dans le gestionnaire de liaison par défaut du système d'exploitation, qui comprend les liens Universal gestionnaires ou l'application du navigateur par défaut. LaSFSafariViewController bibliothèque est également une option prise en charge.

org_internal

Le client OAuth ID dans la demande fait partie d'un projet limitant l' accès aux comptes Google dans un spécifique Google Organisation nuage . Pour plus d' informations sur cette option de configuration voir le type utilisateur section dans la Configuration de votre écran consentement OAuth article d'aide.

redirect_uri_mismatch

Le redirect_uri passé dans la demande d'autorisation ne correspond pas à une redirection autorisé URI pour l'ID client OAuth. Examen autorisé URIs Rediriger à la Google API Console Credentials page.

Le passé redirect_uri peut être invalide pour le type de client.

É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 de la redirection URI régime qu'il utilise. Quel que soit le système, la réponse soit contenir un code d'autorisation ( code ) ou une erreur ( error ). Par exemple, l' error=access_denied indique que l'utilisateur a refusé la demande.

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 : Échangez le code d'autorisation pour les jetons d'actualisation et d'accès

Pour échanger un code d'autorisation pour un jeton d'accès, appelez le https://oauth2.googleapis.com/token point final et définissez les paramètres suivants:

Des champs
client_id L'ID client obtenu à partir de la API ConsoleCredentials page.
client_secret Le secret du client obtenu à partir de la API ConsoleCredentials page.
code Le code d'autorisation renvoyé par la demande initiale.
code_verifier Le code créé vérificateur vous à l' étape 1 .
grant_type Tel que défini dans la spécification OAuth 2.0 , la valeur de ce champ doit être réglé sur authorization_code .
redirect_uri L' une des URIs redirect répertoriés pour votre projet dans le API ConsoleCredentials page pour la donnée client_id .

L'extrait suivant montre 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=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob%3Aauto&
grant_type=authorization_code

Google répond à cette demande en renvoyant un objet JSON qui contient un jeton d'accès de courte durée et un jeton d'actualisation.

La réponse contient les champs suivants :

Des champs
access_token Le jeton que votre application envoie pour autoriser une demande d'API Google.
expires_in Durée de vie restante du jeton d'accès en secondes.
id_token Note: Cette propriété est uniquement retournée si votre demande comprenait une portée d'identité, tels que openid , profile , ou email - email . La valeur est un jeton Web JSON (JWT) qui contient 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 Les champs d'accès accordés par le access_token exprimé comme une liste de délimités par des espaces, des chaînes sensibles à la casse.
token_type Le type de jeton renvoyé. A cette époque, la valeur de ce champ est toujours à Bearer .

L'extrait suivant montre un exemple de réponse :

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

Appel des API Google

Une fois que votre application a obtenu un jeton d'accès, vous pouvez utiliser le jeton pour passer des appels à une API Google au nom d'un compte d'utilisateur donné si la ou les étendues d'accès requises par l'API ont été accordées. Pour ce faire, ajoutez le jeton d' accès dans une requête à l'API en incluant soit un access_token paramètre de requête ou une Authorization en- tête HTTP Bearer valeur. Lorsque cela est possible, l'en-tête HTTP est préférable, car les chaînes de requête ont tendance à être visibles dans les journaux du serveur. Dans la plupart des cas , vous pouvez utiliser une bibliothèque client pour configurer vos appels aux API Google (par exemple, lorsque l' appel de l'API des fichiers Drive ).

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

Exemples HTTP GET

Un appel au drive.files point final (l'API des fichiers Drive) en utilisant l' Authorization: Bearer - tête HTTP pourrait ressembler à ce qui suit. Notez que vous devez spécifier votre propre jeton d'accès :

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

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

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

curl exemples

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

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

Ou, alternativement, 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 périodiquement et deviennent des informations d'identification non valides pour une demande d'API associée. Vous pouvez actualiser un jeton d'accès sans demander l'autorisation à l'utilisateur (y compris lorsque l'utilisateur n'est pas présent) si vous avez demandé un accès hors connexion aux étendues associées au jeton.

Pour actualiser un jeton d'accès, votre application envoie un HTTPS POST demande au serveur d'autorisation de Google ( https://oauth2.googleapis.com/token ) qui comprend les paramètres suivants:

Des champs
client_id L'ID client obtenu à partir de la API Console.
client_secret Le secret du client obtenu à partir de la API Console. (Le client_secret n'est pas applicable aux demandes de clients enregistrés comme Android, iOS ou applications Chrome.)
grant_type Comme défini dans la spécification OAuth 2.0 , la valeur de ce champ doit être réglé sur refresh_token .
refresh_token Le jeton d'actualisation renvoyé par l'échange de code d'autorisation.

L'extrait suivant montre 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 qui contient un nouveau jeton d'accès. L'extrait suivant montre un exemple de réponse :

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

Notez qu'il y a des limites sur le nombre de jetons d'actualisation qui seront émis ; une limite par combinaison client/utilisateur et une autre par utilisateur pour tous les clients. Vous devez enregistrer les jetons d'actualisation dans un stockage à long terme et continuer à les utiliser tant qu'ils restent valides. Si votre application demande trop de jetons d'actualisation, elle peut atteindre ces limites, auquel cas les anciens jetons d'actualisation cesseront de fonctionner.

Révoquer un jeton

Dans certains cas, un utilisateur peut souhaiter révoquer l'accès donné à une application. Un utilisateur peut révoquer l' accès en visitant les paramètres du compte . Voir la section d'accès au site Supprimer ou l' application des sites tiers et des applications avec accès à votre compte document de support pour plus d' informations.

Il est également possible pour une application de révoquer par programmation l'accès qui lui est donné. La révocation par programmation est importante dans les cas où un utilisateur se désabonne, supprime une application ou les ressources API requises par une application ont considérablement changé. En d'autres termes, une partie du processus de suppression peut inclure une demande d'API pour s'assurer que les autorisations précédemment accordées à l'application sont supprimées.

Pour révoquer un programme jeton, votre application fait une demande de https://oauth2.googleapis.com/revoke et comprend le jeton comme 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 a un jeton d'actualisation correspondant, le jeton d'actualisation sera également révoqué.

Si la révocation est traitée avec succès, le code d'état HTTP de la réponse est 200 . Pour les conditions d'erreur, un code d'état HTTP 400 est retourné avec un code d'erreur.

Lectures complémentaires

L'IETF meilleure pratique actuelle OAuth 2.0 pour les applications natives établit un grand nombre des meilleures pratiques documentées ici.