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 conservant leur nom d'utilisateur, leur mot de passe et toute autre information privée. Par exemple, une application peut utiliser OAuth 2.0 pour obtenir l'autorisation aux utilisateurs de stocker des fichiers dans leurs Google Drive.
Les applications installées sont distribuées sur des appareils individuels, et nous partons du principe que ces applications ne peuvent pas garder de secrets. Ils peuvent accéder aux API Google lorsque l'utilisateur utilise l'application ou lorsqu'il utilise l'application s'exécute en arrière-plan.
Ce flux d'autorisation est similaire à celui utilisé pour applications de serveur Web. La principale différence est que les applications installées doivent ouvrir le navigateur du système et fournir un URI de redirection locale à gérer du serveur d'autorisation de Google.
Alternatives
Pour les applications mobiles, vous pouvez utiliser Google Sign-In pour : Android ou iOS Google Sign-In les bibliothèques clientes gèrent l'authentification et l'autorisation de l'utilisateur, que le protocole de niveau inférieur décrit ici.
Pour les applications exécutées sur des appareils non compatibles avec un navigateur système ou dont la saisie est limitée telles que 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 Se connecter sur un téléviseur ou un appareil d'entrée limité.
Bibliothèques et exemples
Nous vous recommandons les bibliothèques et exemples suivants pour vous aider à implémenter le flux OAuth 2.0. décrites dans ce document:
- Bibliothèque AppAuth pour Android
- Bibliothèque AppAuth pour iOS
- OAuth pour les applications: Windows Exemples
Prérequis
Activer les API pour votre projet.
Toute application qui appelle des API Google doit activer ces API dans le API Console
Pour activer une API pour votre projet:
- Open the API Library dans la Google API Console
- If prompted, select a project, or create a new one.
- API Library liste toutes les API disponibles, regroupées par produit. la famille et leur popularité. Si l'API que vous souhaitez activer n'apparaît pas dans la liste, utilisez la recherche pour recherchez-le ou cliquez sur Tout afficher dans la famille de produits à laquelle il appartient.
- 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 auprès du serveur OAuth 2.0 de Google. Les étapes suivantes expliquent comment créer des identifiants pour votre projet. Vos applications peuvent ensuite utiliser les identifiants pour accéder aux API que vous avez activées pour ce projet.
- 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 et d'autorisation. Choisissez le type de client recommandé pour votre votre application, nommez votre client OAuth, puis définissez les autres champs du formulaire en tant que approprié.
Android
- Sélectionnez le type d'application Android.
- Saisissez un nom pour le client OAuth. Ce nom s'affiche sur l'icône Credentials page pour identifier le client.
- Saisissez le nom de package de votre application Android. Cette valeur est définie dans
Attribut
packagede l'élément<manifest>dans le fichier manifeste de votre application. - Saisissez l'empreinte du certificat de signature SHA-1 de la distribution de l'application.
- Si votre application utilise signature d'application Google Play, copiez l'algorithme SHA-1, l'empreinte digitale de la page de signature d'application de la Play Console.
- Si vous gérez votre propre keystore et vos propres clés de signature, utilisez l'utilitaire keytool.
inclus avec Java pour imprimer les informations de certificat dans un format lisible par l'homme. Copiez l'élément
Valeur
SHA1dans la sectionCertificate fingerprintsde Résultat de keytool. Voir Authentifier votre client dans le Documentation sur les API Google pour Android.
- (Facultatif) Validez la propriété de votre appareil Android application.
- Cliquez sur Créer.
iOS
- Sélectionnez le type d'application iOS.
- Saisissez un nom pour le client OAuth. Ce nom s'affiche sur l'icône Credentials page pour identifier le client.
- Saisissez l'identifiant de bundle pour votre application. L'ID du bundle correspond à la valeur CFBundleIdentifier dans le fichier de ressources de la liste de propriétés d'informations de votre application (info.plist). La valeur s'affiche le plus souvent dans le volet "Général" ou Volet des fonctionnalités Éditeur de projet Xcode. L'ID du bundle apparaît également dans la section "Informations générales" la page "Informations sur l'application" Site App Store Connect d'Apple.
- (Facultatif)
Saisissez l'ID App Store de votre application si celle-ci est publiée dans l'App Store d'Apple. L'ID de magasin est une chaîne numérique incluse dans chaque URL de l'App Store d'Apple.
- Ouvrez le App Store d'Apple sur votre appareil iOS ou iPadOS.
- Recherchez votre application.
- Sélectionnez le bouton Partager (carré avec une flèche vers le haut).
- Sélectionnez Copier le lien.
- Collez le lien dans un éditeur de texte. L'ID App Store correspond à la dernière partie de l'URL.
Exemple :
https://apps.apple.com/app/google/id284815942
- (Facultatif)
Saisissez votre ID d'équipe. Voir Trouver 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 s'affiche sur l'icône Credentials page pour identifier le client.
- Saisissez l'ID Microsoft Store à 12 caractères de votre application. Vous trouverez cette valeur dans Centre des partenaires Microsoft le Identité de l'application dans la section "Gestion des applications".
- Cliquez sur Créer.
Pour les applications UWP, le schéma d'URI personnalisé ne peut pas comporter plus de 39 caractères.
Schéma d'URI personnalisé (Android, iOS, UWP)
Les schémas d'URI personnalisés sont une forme de lien profond qui ouvre votre application à l'aide d'un schéma défini personnalisé.
Alternative à l'utilisation de schémas d'URI personnalisés sur AndroidUtilisez les SDK Google Sign-In pour Android qui envoie la réponse OAuth 2.0 directement à votre application, éliminant ainsi le besoin d'une l'URI de redirection.
Migrer vers le SDK Google Sign-In pour Android
Si vous utilisez actuellement un schéma personnalisé pour votre intégration OAuth sur Android, vous devez effectuez les actions ci-dessous pour migrer complètement vers l'utilisation de Google Sign-In recommandée pour SDK Android:
- Mettez à jour votre code pour utiliser le SDK Google Sign-In.
- Désactiver la compatibilité avec le schéma personnalisé dans la console Google APIs
Suivez les étapes ci-dessous pour migrer vers le SDK Google Sign-In pour Android:
-
Mettez à jour votre code pour utiliser le SDK Android Google Sign-In:
-
Examinez votre code pour identifier votre position
L'envoi d'une requête au serveur OAuth 2.0 de Google Si vous utilisez un schéma personnalisé, votre demande se présentera comme suit:
https://accounts.google.com/o/oauth2/v2/auth? scope=<SCOPES>& response_type=code& &state=<STATE>& redirect_uri=com.example.app:/oauth2redirect& client_id=<CLIENT_ID>
com.example.app:/oauth2redirectest l'URI de redirection du schéma personnalisé dans ci-dessus. Consultez le Définition du paramètreredirect_uripour en savoir plus sur le format de la valeur du schéma d'URI personnalisé. -
Notez les paramètres de requête
scopeetclient_idqui vous devez configurer le SDK Google Sign-In. -
Suivez le
Commencer à intégrer Google Sign-In à votre application Android
pour configurer le SDK. Vous pouvez ignorer
Obtenez l'ID client OAuth 2.0 du serveur backend comme vous le feriez pour réutiliser l'ID.
Le
client_idque vous avez récupéré à l'étape précédente. -
Suivez le
Activer l'accès à l'API côté serveur
instructions. Voici les étapes à suivre:
-
Utilisez la méthode
getServerAuthCodepour récupérer un code d'autorisation pour le champs d'application pour lesquels vous demandez une autorisation. - Envoyez le code d'autorisation au backend de votre application pour l'échanger contre un accès et actualiser à partir d'un jeton d'accès.
- Utilisez le jeton d'accès récupéré pour appeler les API Google au nom de l'utilisateur.
-
Utilisez la méthode
-
Examinez votre code pour identifier votre position
L'envoi d'une requête au serveur OAuth 2.0 de Google Si vous utilisez un schéma personnalisé, votre demande se présentera comme suit:
-
Désactivez la compatibilité avec le schéma personnalisé dans la console Google APIs:
- Accédez à votre Identifiants OAuth 2.0 et sélectionnez votre client Android.
- Accédez à la section Paramètres avancés, puis décochez la case Cochez la case Enable Custom URI Scheme (Activer le schéma d'URI personnalisé), puis cliquez sur Save (Enregistrer) dans désactiver la compatibilité avec les schémas d'URI personnalisés.
Activer le schéma d'URI personnalisé
Si l'alternative recommandée ne fonctionne pas pour vous, vous pouvez activer les schémas d'URI personnalisés pour votre client Android en suivant les instructions ci-dessous:- Accédez à votre la liste d'identifiants OAuth 2.0 ; sélectionnez votre client Android.
- Accédez à la section Paramètres avancés, puis cochez l'option Cochez la case Enable Custom URI Scheme (Activer le schéma d'URI personnalisé), puis cliquez sur Save (Enregistrer) pour l'activer. schémas d'URI personnalisés.
Utilisez les API Chrome Identity qui envoie la réponse OAuth 2.0 directement à votre application, éliminant ainsi le besoin d'une l'URI de redirection.
Valider la propriété d'une application (Android, Chrome)
Vous pouvez confirmer que vous êtes le propriétaire de votre application afin de réduire le risque d'usurpation d'identité.
Android
Pour terminer la procédure de validation, vous pouvez utiliser votre compte de développeur Google Play si vous en possédez une et que votre application est enregistrée sur le Google Play Console : Les éléments suivants : pour que la validation puisse aboutir:
- Vous devez disposer d'une application enregistrée dans la Google Play Console avec le même et l'empreinte du certificat de signature SHA-1 en tant que client OAuth Android que vous effectuant la validation.
- Vous devez disposer d'une autorisation Administrateur pour l'application dans le Google Play Console. En savoir plus sur la gestion des accès dans la Google Play Console.
Dans la section Verify App Ownership (Valider la propriété de l'application) du client Android, cliquez sur l'icône Valider la propriété pour terminer la procédure de validation.
Si la validation réussit, une notification s'affiche pour confirmer le succès. de la procédure de validation. Sinon, un message d'erreur s'affichera.
Pour résoudre un problème de validation, procédez comme suit:
- Assurez-vous que l'application que vous validez est enregistrée dans la Google Play Console.
- Assurez-vous de disposer de l'autorisation Administrateur pour l'application dans le Google Play Console.
Chrome
Pour terminer le processus de validation, vous devez utiliser votre compte de développeur Chrome Web Store. Pour réussir la validation, vous devez remplir les conditions suivantes:
- Vous devez disposer d'un article enregistré dans le Tableau de bord du développeur Chrome Web Store avec le même ID d'élément que le client OAuth de l'extension Chrome que vous exécutez la vérification.
- Vous devez être éditeur de l'article Chrome Web Store. En savoir plus sur la gestion des accès dans le tableau de bord du développeur Chrome Web Store.
Dans la section Valider la propriété de l'application du client de l'extension Chrome, cliquez sur le bouton Valider la propriété pour terminer la procédure de validation.
Remarque:Veuillez patienter quelques minutes avant d'effectuer la procédure de validation. pour accorder l'accès à votre compte.
Si la validation réussit, une notification s'affiche pour confirmer le succès. de la procédure de validation. Sinon, un message d'erreur s'affichera.
Pour résoudre un problème de validation, procédez comme suit:
- Assurez-vous qu'il existe un élément enregistré dans le tableau de bord du développeur Chrome Web Store avec le Même ID d'article que le client OAuth de l'extension Chrome pour lequel vous effectuez la validation.
- Assurez-vous d'être un éditeur de l'application, c'est-à-dire l'éditeur individuel. de l'application ou un membre de l'éditeur de groupe de l'application. En savoir plus sur la gestion des accès dans le tableau de bord du développeur Chrome Web Store.
- Si vous venez de mettre à jour la liste des éditeurs de votre groupe, vérifiez que les éditeurs de groupe est synchronisée dans le tableau de bord du développeur Chrome Web Store. En savoir plus sur la synchronisation de votre liste d'adhésion des éditeurs.
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 votre serveur Web local. Cela est possible sur de nombreuses plates-formes, mais pas sur toutes. Toutefois, si votre plate-forme est compatible, 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 afficher 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 du formulaire | Définissez le type d'application sur Application de bureau. |
Copier/Coller manuel
Identifier les niveaux d'accès
Les niveaux d'accès permettent à votre application de ne demander l'accès qu'aux ressources dont elle a besoin, tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils accordent à votre application. Il existe donc peut représenter une relation inverse entre le nombre de champs d'application demandés et la probabilité l'obtention du consentement de l'utilisateur.
Avant de commencer à implémenter l'autorisation OAuth 2.0, nous vous recommandons d'identifier les champs d'application auxquelles votre application a besoin d'une autorisation d'accès.
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
Les étapes suivantes montrent comment votre application interagit avec le serveur OAuth 2.0 de Google pour obtenir le consentement d'un utilisateur pour envoyer une requête API au nom de l'utilisateur. Votre application doit inclure avant de pouvoir exécuter une requête API Google nécessitant l'autorisation de l'utilisateur.
Étape 1: Générer un outil de vérification du code et un test
Google accepte la clé de vérification pour l'échange de code. (PKCE) pour sécuriser davantage le flux de l'application installée. 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 pour obtenir le code d'autorisation.
Créer l'outil de vérification du code
Un code_verifier est une chaîne cryptographique aléatoire à entropie élevée utilisant la chaîne
caractères [A-Z] / [a-z] / [0-9] /"-" / "." / "_" / "~", d'une longueur minimale de 43 caractères
et ne doit pas dépasser 128 caractères.
L'outil de vérification du code doit avoir une entropie suffisante pour qu'il soit difficile de deviner la valeur.
Créer le défi de code
Il existe deux méthodes pour créer le défi de code.
| Méthodes de génération de défis de code | |
|---|---|
| S256 (recommandé) | Le défi de code est le hachage SHA256 encodé en Base64URL (sans marge intérieure) du code
vérificateur.
|
| ordinaire | Le défi de code a la même valeur que l'outil de vérification du 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 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
de session active,
authentifie l'utilisateur et obtient son consentement. Le point de terminaison n'est accessible que via SSL,
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 éléments applications:
| 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 la manière dont le serveur d'autorisation de Google envoie une réponse à votre application. Il y a plusieurs options de redirection sont disponibles pour les applications installées. identifiants d'autorisation avec une méthode de redirection particulière à l'esprit. La valeur doit correspondre exactement à l'un des URI de redirection autorisés pour le protocole OAuth 2.0
que vous avez configuré dans le
API Console
Credentials pageSi cette valeur ne correspond pas à une
un URI autorisé, vous obtenez une erreur Le tableau ci-dessous indique la valeur de 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
A délimité par des espaces des champs d'application qui identifient les ressources auxquelles votre application pourrait accéder au nom de l'utilisateur. Ces valeurs déterminent l'écran de consentement que Google présente aux utilisateurs utilisateur. Les niveaux d'accès permettent à votre application de ne demander l'accès qu'aux ressources dont elle a besoin tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils accordent application. Ainsi, il existe une relation inverse entre le nombre de champs d'application demandés et la probabilité d'obtenir le consentement de l'utilisateur. |
||||||
code_challenge |
Recommandé
Spécifie un |
||||||
code_challenge_method |
Recommandé
Spécifie la méthode utilisée pour encoder un élément |
||||||
state |
Recommandé
Spécifie toute valeur de chaîne utilisée par votre application pour maintenir l'état entre vos
la requête d'autorisation et la réponse du serveur d'autorisation.
Le serveur renvoie la valeur exacte que vous envoyez en tant que paire Vous pouvez utiliser ce paramètre à différentes fins, par exemple pour rediriger l'utilisateur vers le
la ressource appropriée dans votre application, en envoyant des nonces et en limitant les requêtes intersites
falsification. Étant donné que votre |
||||||
login_hint |
Optional
Si votre application sait quel utilisateur tente de s'authentifier, elle peut utiliser ce paramètre pour fournir un indice au serveur d'authentification Google. Le serveur utilise l'indice pour simplifier le processus de connexion soit en préremplissant le champ de l'adresse e-mail dans le formulaire de connexion, soit en en sélectionnant la session multiconnexion appropriée. Définissez la valeur du paramètre sur une adresse e-mail ou un identifiant |
||||||
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.
comme paramètre facultatif state. Chaque URL contient des sauts de ligne et des espaces
la 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 rebouclage
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
Étape 3: Google invite l'utilisateur à donner son consentement
Au cours de cette étape, l'utilisateur décide d'accorder ou non l'accès demandé à votre application. À cette adresse étape, Google affiche une fenêtre de consentement indiquant le nom de votre application et l'API Google services auxquels il demande l'autorisation d'accéder avec les informations d'identification de l'utilisateur et un résumé des niveaux d'accès à accorder. La l'utilisateur peut alors consentir à accorder l'accès à un ou plusieurs champs d'application demandés par votre application ou refuser la demande.
Votre application n'a rien à faire à ce stade, car elle attend la réponse de Serveur OAuth 2.0 de Google indiquant si un accès a été accordé Cette réponse est expliquée dans l'étape suivante.
Erreurs
Les requêtes envoyées au point de terminaison d'autorisation OAuth 2.0 de Google peuvent afficher des messages d'erreur destinés aux utilisateurs au lieu des flux d'authentification et d'autorisation attendus. Codes d'erreur courants et suggestions résolutions sont indiquées ci-dessous.
admin_policy_enforced
Le compte Google ne peut pas autoriser un ou plusieurs champs d'application demandés en raison des règles de leur administrateur Google Workspace. Consultez l'article d'aide Administrateur Google Workspace Contrôlez les enregistrements les applications internes accèdent aux données Google Workspace pour en savoir plus sur la façon dont un administrateur peut restreindre l'accès à tous les niveaux d'accès ou des niveaux d'accès restreints jusqu'à ce que l'accès soit explicitement accordé à votre ID client OAuth.
disallowed_useragent
Le point de terminaison de l'autorisation est affiché dans un user-agent intégré non autorisé par le Règles OAuth 2.0
Android
Les développeurs Android peuvent rencontrer ce message d'erreur lorsqu'ils ouvrent des demandes d'autorisation dans
android.webkit.WebView
Les développeurs doivent plutôt utiliser des bibliothèques Android telles que
Google Sign-In pour Android ou OpenID Foundation
AppAuth pour Android :
Les développeurs Web peuvent rencontrer cette erreur lorsqu'une application Android ouvre un lien Web général dans un user-agent intégré et un utilisateur accède au point de terminaison d'autorisation OAuth 2.0 de Google depuis sur votre site. Les développeurs doivent autoriser l'ouverture de liens généraux dans le gestionnaire de liens par défaut du système d'exploitation, qui inclut à la fois Android App Links ou l'application de navigateur par défaut. La Onglets personnalisés Android bibliothèque est également une option prise en charge.
iOS
Les développeurs iOS et macOS peuvent rencontrer cette erreur lorsqu'ils ouvrent des demandes d'autorisation dans
WKWebView
Les développeurs doivent plutôt utiliser des bibliothèques iOS telles que
Google Sign-In pour iOS ou OpenID Foundation
AppAuth pour iOS :
Les développeurs Web peuvent rencontrer cette erreur lorsqu'une application iOS ou macOS ouvre un lien Web général dans
un user-agent intégré et un utilisateur accède au point de terminaison d'autorisation OAuth 2.0 de Google
sur votre site. Les développeurs doivent autoriser l'ouverture de liens généraux dans le gestionnaire de liens par défaut du
système d'exploitation, qui inclut à la fois
Liens universels
ou l'application de navigateur par défaut. La
SFSafariViewController
bibliothèque est également
une option prise en charge.
org_internal
L'ID client OAuth de la requête fait partie d'un projet limitant l'accès aux comptes Google dans un spécifiques Organisation Google Cloud. Pour en savoir plus sur cette option de configuration, consultez la Type d'utilisateur de l'article d'aide "Configurer l'écran de consentement OAuth".
invalid_grant
Si vous utilisez un
vérificateur de code
challenge, le paramètre code_callenge est incorrect ou manquant. Vérifiez que la propriété
Le paramètre code_challenge est correctement défini.
Lors de l'actualisation d'un jeton d'accès, il est possible que le jeton ait expiré ou a été invalidée. Authentifiez à nouveau l'utilisateur et demandez son consentement pour obtenir de nouveaux jetons. Si vous poursuivez pour que ce message d'erreur s'affiche, vérifiez que votre application est correctement configurée et que vous n'avez pas en utilisant les jetons et les paramètres appropriés dans votre requête. Sinon, le compte utilisateur peut avoir supprimé ou désactivé.
redirect_uri_mismatch
L'élément redirect_uri transmis dans la demande d'autorisation ne correspond à aucune
URI de redirection pour l'ID client OAuth. Examinez les URI de redirection autorisés dans le fichier
Google API Console Credentials page
La valeur redirect_uri transmise n'est peut-être pas valide pour le type de client.
Le paramètre redirect_uri peut faire référence au flux OAuth hors bande (OOB) qui a
est obsolète et n'est plus compatible. Consultez le
guide de migration pour mettre à jour votre
l'intégration.
invalid_request
Un problème est survenu avec votre demande. Plusieurs raisons peuvent expliquer ce problème:
- Le format de la requête n'est pas correct.
- Il manquait des paramètres obligatoires dans la requête
- La requête utilise une méthode d'autorisation non compatible avec Google. Valider votre protocole OAuth utilise une méthode d'intégration recommandée
- Un schéma personnalisé est utilisé pour l'URI de redirection : si le message d'erreur s'affiche Le schéma d'URI personnalisé n'est pas compatible avec les applications Chrome ni Schéma d'URI personnalisé n'est pas activé pour votre client Android, cela signifie que vous utilisez un URI personnalisé qui n'est pas compatible avec les applications Chrome et est désactivé par défaut Android En savoir plus sur les schémas d'URI personnalisés alternatives
É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
schéma d'URI de redirection qu'il utilise. Quel que soit le schéma,
contiendra un code d'autorisation (code) ou une erreur
(error). Par exemple, error=access_denied indique que l'utilisateur
a refusé la demande.
Si l'utilisateur vous donne accès à votre application, vous pouvez échanger le code d'autorisation un jeton d'accès et un jeton d'actualisation, comme décrit à l'étape suivante.
Étape 5: Échangez le code d'autorisation contre une actualisation et un accès jetons
Pour échanger un code d'autorisation contre un jeton d'accès, appelez la méthode
https://oauth2.googleapis.com/token et définissez les paramètres suivants:
| Champs | |
|---|---|
client_id |
ID client obtenu à partir de l' API Console Credentials page |
client_secret |
Code secret du client obtenu à partir de l' API Console Credentials page |
code |
Code d'autorisation renvoyé par la requête initiale. |
code_verifier |
L'outil de vérification du code que vous avez créé dans Étape 1 : |
grant_type |
Tel que défini dans la norme OAuth 2.0
spécification, la valeur de ce champ doit être définie sur authorization_code. |
redirect_uri |
L'un des URI de redirection listés pour votre projet dans la section
API Console
Credentials page pour la valeur
client_id |
L'extrait de code suivant présente un exemple de requête:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7& client_id=your_client_id& client_secret=your_client_secret& redirect_uri=http://127.0.0.1:9004& grant_type=authorization_code
Google répond à cette requête en renvoyant un objet JSON contenant un accès de courte durée et un jeton d'actualisation.
La réponse contient les champs suivants :
| Champs | |
|---|---|
access_token |
Jeton envoyé par votre application pour autoriser une requête API Google. |
expires_in |
Durée de vie restante du jeton d'accès, en secondes. |
id_token |
Remarque:Cette propriété n'est renvoyée que si votre requête inclut un champ d'application d'identité,
comme openid, profile ou email. Cette valeur est une
Jeton Web JSON (JWT, JSON Web Token) contenant des informations d'identité signées numériquement sur le
utilisateur. |
refresh_token |
Jeton que vous pouvez utiliser pour obtenir un nouveau jeton d'accès. Les jetons d'actualisation sont valides jusqu'au l'utilisateur révoque l'accès. 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 le access_token, exprimés sous la forme d'une liste de
délimitées par des espaces et sensibles à la casse. |
token_type |
Type de jeton renvoyé. Pour le moment, la valeur de ce champ est toujours définie sur
Bearer |
L'extrait de code suivant 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"
}
Appeler des API Google
Une fois que votre application a obtenu un jeton d'accès, vous pouvez l'utiliser pour effectuer des appels vers
pour le compte d'un service
compte utilisateur si les niveaux d'accès requis par l'API ont été accordés. Pour ce faire, incluez
le jeton d'accès dans une requête adressée à l'API en incluant une requête access_token
ou une valeur Bearer d'en-tête HTTP Authorization. Si possible,
l'en-tête HTTP est préférable, car les chaînes de requête ont tendance à être visibles dans les journaux du serveur. Dans la plupart des cas
vous pouvez utiliser une bibliothèque cliente pour configurer vos appels aux API Google (par exemple, lorsque
appelez l'API Drive Files).
Vous pouvez essayer toutes les API Google et consulter leurs champs d'application à la OAuth 2.0 Playground.
Exemples de requêtes HTTP GET
Un appel à la fonction
drive.files
(API Drive Files) via le protocole HTTP Authorization: Bearer
peut se présenter comme suit. Notez que vous devez spécifier votre propre jeton d'accès:
GET /drive/v2/files HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
Voici un appel à la même API pour l'utilisateur authentifié à l'aide de access_token.
paramètre de chaîne de requête:
GET https://www.googleapis.com/drive/v2/files?access_token=access_token
curl exemples
Vous pouvez tester ces commandes avec l'application de ligne de commande curl. Voici un
exemple qui utilise l'option d'en-tête HTTP (recommandé):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files
Vous pouvez également utiliser l'option de paramètre de chaîne de requête:
curl https://www.googleapis.com/drive/v2/files?access_token=access_token
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. Toi peut actualiser un jeton d'accès sans demander l'autorisation à l'utilisateur (y compris lorsqu'il est absente) si vous avez demandé un accès hors connexion aux champs d'application associés au jeton.
Pour actualiser un jeton d'accès, votre application envoie un POST HTTPS
au serveur d'autorisation de Google (https://oauth2.googleapis.com/token) qui
comprend les paramètres suivants:
| Champs | |
|---|---|
client_id |
ID client obtenu à partir de API Console. |
client_secret |
Code secret du client obtenu à partir de API Console.
(Le client_secret ne s'applique pas aux requêtes des clients enregistrés sous le nom
applications Android, iOS ou Chrome).
|
grant_type |
En tant que
définis dans le
spécification OAuth 2.0,
la valeur de ce champ doit être définie sur refresh_token. |
refresh_token |
Jeton d'actualisation renvoyé par l'échange de code d'autorisation. |
L'extrait de code suivant présente un exemple de requête:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded client_id=your_client_id& client_secret=your_client_secret& refresh_token=refresh_token& grant_type=refresh_token
Tant que l'utilisateur n'a pas révoqué l'accès accordé à l'application, le serveur de jetons La fonction renvoie un objet JSON contenant un nouveau jeton d'accès. L'extrait de code suivant montre un exemple réponse:
{
"access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
"expires_in": 3920,
"scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
"token_type": "Bearer"
}
Notez que le nombre de jetons d'actualisation qui seront émis est limité. une limite par combinaison client/utilisateur et une autre par utilisateur pour tous les clients. Enregistrer les jetons d'actualisation dans un espace de stockage à long terme et continuent à les utiliser tant qu'ils sont valides. Si votre application demande trop de jetons d'actualisation, il risque de dépasser ces limites, auquel cas les jetons d'actualisation plus anciens cesseront de fonctionner.
Révoquer un jeton
Dans certains cas, un utilisateur peut souhaiter révoquer l'accès accordé à une application. Un utilisateur peut révoquer l'accès en accédant à la page Paramètres du compte. Consultez le Supprimer de la section "Sites et applications tiers" applications ayant accès à votre compte pour en savoir plus.
Une application peut également révoquer de manière programmatique l'accès qui lui est accordé. La révocation par programmation est importante lorsqu'un utilisateur se désabonne, supprime application ou les ressources d'API requises par une application ont changé de manière significative. Autrement dit, peut inclure une requête API pour garantir que les autorisations précédemment accordées accordées à l'application sont supprimées.
Pour révoquer un jeton de manière programmatique, votre application envoie une requête à
https://oauth2.googleapis.com/revoke et inclut le jeton en tant que paramètre:
curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
https://oauth2.googleapis.com/revoke?token={token}
Il peut s'agir d'un jeton d'accès ou d'un jeton d'actualisation. Si le jeton est un jeton d'accès et qu'il possède le jeton d'actualisation correspondant, il sera également révoqué.
Si la révocation a bien été traitée, le code d'état HTTP de la réponse est
200 Pour les conditions d'erreur, un code d'état HTTP 400 est renvoyé avec
par un code d'erreur.
Documentation complémentaire
Les bonnes pratiques de l'IETF OAuth 2.0 for Les applications natives établissent bon nombre des bonnes pratiques décrites ici.