OAuth 2.0 pour les applications mobiles et de bureau

Remarque:Si vous débutez avec OAuth 2.0, nous vous recommandons de lire le Présentation d'OAuth 2.0 avant de commencer La résume les flux OAuth 2.0 compatibles avec Google, ce qui vous permet de vérifier que vous avez sélectionné le flux adapté à votre application.

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 l'API YouTube Data.

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 pour mettre en ligne des vidéos sur la chaîne YouTube d'un utilisateur.

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:

1. Open the API Library dans la Google API Console
2. If prompted, select a project, or create a new one.
3. Accédez à la page Bibliothèque pour rechercher et activer l'API YouTube Data. Rechercher d'autres les API que votre application utilisera et les activeront également.

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.

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 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

1. Sélectionnez le type d'application Android.
2. Saisissez un nom pour le client OAuth. Ce nom s'affiche sur l'icône Credentials page pour identifier le client.
3. Saisissez le nom de package de votre application Android. Cette valeur est définie dans 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 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 SHA1 dans la section Certificate fingerprints de Résultat de keytool. Voir Authentifier votre client dans le Documentation sur les API Google pour Android.
5. (Facultatif) Validez la propriété de votre appareil Android application.
6. Cliquez sur Créer.

iOS

1. Sélectionnez le type d'application iOS.
2. Saisissez un nom pour le client OAuth. Ce nom s'affiche sur l'icône Credentials page pour identifier le client.
3. 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.
4. (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.

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

5. (Facultatif)

   Saisissez votre ID d'équipe. Voir Trouver votre ID d'équipe dans la documentation du compte de développeur Apple.

6. Cliquez sur Créer.

UWP

1. Sélectionnez le type d'application Plate-forme Windows universelle.
2. Saisissez un nom pour le client OAuth. Ce nom s'affiche sur l'icône Credentials page pour identifier le client.
3. 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".
4. 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é.

Important:Les schémas d'URI personnalisés ne sont plus compatibles avec les nouvelles applications Chrome et sont sont désactivées par défaut sur les nouveaux clients Android en raison du risque d'usurpation d'identité.

Alternative à l'utilisation de schémas d'URI personnalisés sur Android

Utilisez 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:

1. Mettez à jour votre code pour utiliser le SDK Google Sign-In.
2. Désactiver la compatibilité avec le schéma personnalisé dans la console Google APIs

<ph type="x-smartling-placeholder">

</ph> Remarque:Vous devez effectuer et déployer vos mises à jour de code (en tenant compte du temps d'adoption par votre base d'utilisateurs ou sur vos appareils plus anciens) avant de désactiver la prise en charge des schémas personnalisés dans le la console Google APIs pour éviter que les utilisateurs Message d'erreur invalid_request lorsqu'ils essaient d'utiliser votre application.

Suivez les étapes ci-dessous pour migrer vers le SDK Google Sign-In pour Android:

1. Mettez à jour votre code pour utiliser le SDK Android Google Sign-In:
   1. 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:/oauth2redirect est l'URI de redirection du schéma personnalisé dans ci-dessus. Consultez le Définition du paramètre redirect_uri pour en savoir plus sur le format de la valeur du schéma d'URI personnalisé.
   2. Notez les paramètres de requête scope et client_id qui vous devez configurer le SDK Google Sign-In.
      Remarque:Si vous utilisez une bibliothèque tierce, consultez les de configuration Terraform pour trouver ces informations.
   3. 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_id que vous avez récupéré à l'étape précédente.
   4. Suivez le Activer l'accès à l'API côté serveur instructions. Voici les étapes à suivre:
      1. Utilisez la méthode getServerAuthCode pour récupérer un code d'autorisation pour le champs d'application pour lesquels vous demandez une autorisation.
      2. 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.
      3. Utilisez le jeton d'accès récupéré pour appeler les API Google au nom de l'utilisateur.
      <ph type="x-smartling-placeholder">
      </ph> Remarque:Si votre application ne nécessite pas d'accès hors connexion, suivez les <ph type="x-smartling-placeholder"></ph> suivez ces instructions pour demander l'accès aux API côté client.
2. Désactivez la compatibilité avec le schéma personnalisé dans la console Google APIs:
   1. Accédez à votre Identifiants OAuth 2.0 et sélectionnez votre client Android.
   2. 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:

1. Accédez à votre la liste d'identifiants OAuth 2.0 ; sélectionnez votre client Android.
2. 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.

Alternative à l'utilisation de schémas d'URI personnalisés dans les applications Chrome

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

Remarque:La validation de la propriété des applications Android n'est actuellement disponible que pour Google Play. applications.

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 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 l'é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)

Important:L'option de redirection d'adresse IP de bouclage est OBSOLÈTE pour les types de clients OAuth Android, application Chrome et iOS. Vérifiez l'adresse IP de bouclage guide de migration des adresses pour savoir comment migrer vers une alternative compatible.

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.

Remarque:Consultez les Définition du paramètre redirect_uri pour plus d'informations sur l'adresse IP de bouclage. Il est également possible d'utiliser localhost au lieu de l'adresse IP de bouclage, mais cette configuration peut entraîner des problèmes avec les pare-feu clients. La plupart des pare-feu autorisent la communication de bouclage.

Copier/Coller manuel

Important:L'option de copier-coller manuel, également appelée hors bande, est ne sont plus compatibles. Consultez le guide de migration OOB. pour obtenir des instructions sur la migration vers une alternative sécurisée.

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.

Remarque:L'autorisation incrémentielle n'est pas prise en charge pour les applications installées ou appareils.

La version 3 de l'API YouTube Data utilise les champs d'application suivants:

Niveaux d'accès
https://www.googleapis.com/auth/youtube	Gérez votre compte YouTube.
https://www.googleapis.com/auth/youtube.channel-memberships.creator	Consulter la liste des membres actuellement actifs de votre chaîne, leur niveau actuel et leur date de souscription
https://www.googleapis.com/auth/youtube.force-ssl	Afficher, modifier et supprimer définitivement vos vidéos, notes, commentaires et sous-titres YouTube
https://www.googleapis.com/auth/youtube.readonly	Consultez votre compte YouTube.
https://www.googleapis.com/auth/youtube.upload	Gérez vos vidéos YouTube.
https://www.googleapis.com/auth/youtubepartner	Affichez et gérez vos éléments et le contenu associé sur YouTube.
https://www.googleapis.com/auth/youtubepartner-channel-audit	Affichez les informations privées sur votre chaîne YouTube pertinentes pendant le processus d'audit avec un partenaire YouTube.

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.

Si votre application publique utilise des champs d'application qui autorisent l'accès certaines données utilisateur, elle doit suivre une procédure de validation. Si la mention non validé application à l'écran lorsque vous la testez, vous devez envoyer une de validation pour le supprimer. En savoir plus sur applications non validées et obtenez des réponses à vos questions sur questions fréquentes sur la validation des applications dans le centre d'aide.

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 l'autorisation d'un utilisateur pour effectuer 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. code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
ordinaire	Le défi de code a la même valeur que l'outil de vérification du 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 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 à un URI autorisé, vous obtenez une erreur redirect_uri_mismatch. Le tableau ci-dessous indique la valeur de paramètre redirect_uri appropriée 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. Pour être valide, le schéma personnalisé doit contenir un point. com.googleusercontent.apps.123 est la notation DNS inverse du ID client. redirect_uri_path est un composant de chemin d'accès facultatif, tel que /oauth2redirect Notez que le chemin d'accès doit commencer par un seul différente des URL HTTP standards. <ph type="x-smartling-placeholder"> </ph> Remarque : Les schémas d'URI personnalisés ne sont plus compatibles avec les applications et sont désactivés par défaut sur Android. En savoir plus des alternatives aux schémas personnalisés pour les applications Android et Chrome. Adresse IP de rebouclage http://127.0.0.1:port ou http://[::1]:port Demandez à votre plate-forme l'adresse IP de bouclage appropriée et lancez une requête sur un port disponible aléatoirement. Remplacez port par la valeur réelle numéro de port que votre application écoute. Notez que la prise en charge de l'option de redirection d'adresse IP de bouclage sur les appareils mobiles apps est <ph type="x-smartling-placeholder"></ph> OBSOLÈTE.
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 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. La version 3 de l'API YouTube Data utilise les champs d'application suivants: Niveaux d'accès https://www.googleapis.com/auth/youtube Gérez votre compte YouTube. https://www.googleapis.com/auth/youtube.channel-memberships.creator Consulter la liste des membres actuellement actifs de votre chaîne, leur niveau actuel et leur date de souscription https://www.googleapis.com/auth/youtube.force-ssl Afficher, modifier et supprimer définitivement vos vidéos, notes, commentaires et sous-titres YouTube https://www.googleapis.com/auth/youtube.readonly Consultez votre compte YouTube. https://www.googleapis.com/auth/youtube.upload Gérez vos vidéos YouTube. https://www.googleapis.com/auth/youtubepartner Affichez et gérez vos éléments et le contenu associé sur YouTube. https://www.googleapis.com/auth/youtubepartner-channel-audit Affichez les informations privées sur votre chaîne YouTube pertinentes pendant le processus d'audit avec un partenaire YouTube. Le document sur les champs d'application de l'API OAuth 2.0 fournit une liste complète des champs d'application que vous pouvez utiliser pour accéder aux API Google.
code_challenge	Recommandé Spécifie un code_verifier encodé qui sera utilisé côté serveur lors de l'échange du code d'autorisation. Voir créer du code challenge ci-dessus.
code_challenge_method	Recommandé Spécifie la méthode utilisée pour encoder un élément code_verifier qui sera utilisé lors de l'échange du code d'autorisation. Ce paramètre doit être utilisé avec le paramètre le paramètre code_challenge décrit ci-dessus. La valeur de code_challenge_method est défini par défaut sur plain s'il n'est pas présent dans la requête qui inclut un code_challenge Les seules valeurs acceptées pour ce paramètre sont S256 ou plain.
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 name=value dans le paramètre Identifiant de fragment d'URL (#) des redirect_uri après que l'utilisateur a donné son accord ou refusé demande d'accès. 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 redirect_uri peut être deviné, l'utilisation d'un state peut vous assurer qu'une connexion entrante est le résultat d'une d'authentification unique. 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 Assurez-vous également que la requête et la réponse proviennent du même navigateur, en offrant une protection contre les attaques demande intersites falsification. Consultez le OpenID Connect pour obtenir un exemple de création et de confirmation d'un jeton state. Important:Le client OAuth doit empêcher CSRF, comme indiqué dans la Spécification OAuth2 . Pour ce faire, vous pouvez utiliser le paramètre state pour maintenir entre votre demande d'autorisation et la réponse du serveur d'autorisation.
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 sub, soit correspondant à l'ID Google de l'utilisateur.

Remarque:L'autorisation incrémentielle avec les applications installées n'est pas prise en charge en raison au fait que le client ne peut pas garder le client_secret confidentiel.

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.

Chaque URL demande l'accès à un champ d'application qui autorise l'accès en vue de consulter les compte YouTube.

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=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly&
 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=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly&
 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 ont été supprimées ou désactivées.

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 du 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 répertorié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 incluait 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

Important:Votre application doit stocker les deux jetons dans un environnement dans un emplacement de longue durée accessible entre différents appels de votre application. La Le jeton d'actualisation permet à votre application d'obtenir un nouveau jeton d'accès expire. Par conséquent, si votre application perd le jeton d'actualisation, l'utilisateur doit répéter l'opération Flux de consentement OAuth 2.0 afin que votre application puisse obtenir un nouveau jeton d'actualisation

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

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

Remarque:Votre application doit ignorer tous les champs non reconnus inclus dans la réponse.

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 appeler l'API YouTube Data).

Remarque : L'API YouTube Data n'est compatible qu'avec les comptes de service pour YouTube. les propriétaires de contenu qui possèdent et gèrent plusieurs chaînes YouTube, les maisons de disques et les studios de cinéma.

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

Exemples de requête HTTP GET

Un appel à la fonction youtube.channels (l'API YouTube Data) via le point de terminaison HTTP Authorization: Bearer peut se présenter comme suit. Notez que vous devez spécifier votre propre jeton d'accès:

GET /youtube/v3/channels?part=snippet&mine=true 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/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

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/youtube/v3/channels?part=snippet&mine=true

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

curl https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

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.

Remarque:Une fois la révocation terminée, avant que la révocation prenne effet.

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.

Implémenter la protection multicompte

Une mesure supplémentaire à prendre pour protéger l'expérience utilisateur implémente les stratégies d'enchères à l'aide du service de protection multicompte de Google. Ce service vous permet vous abonner aux notifications d'événements liés à la sécurité, qui fournissent des informations à votre application sur des modifications majeures au compte utilisateur. Vous pouvez ensuite utiliser ces informations pour prendre des mesures en fonction de comment vous décidez de répondre aux événements.

Voici quelques exemples de types d'événements envoyés à votre application par le service de protection multicompte de Google:

• https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
• https://schemas.openid.net/secevent/oauth/event-type/token-revoked
• https://schemas.openid.net/secevent/risc/event-type/account-disabled

Consultez le Protéger les comptes utilisateur grâce à la page "Protection multicompte" pour en savoir plus sur l'implémentation de la protection multicompte et obtenir la liste complète des événements disponibles.