Ce document explique comment implémenter l'autorisation OAuth 2.0 pour accéder à l'API YouTube Analytics ou à l'API YouTube Reporting depuis une application Web JavaScript. OAuth 2.0 permet aux utilisateurs de partager certaines données 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 de récupérer les données YouTube Analytics d'une chaîne.
Ce flux OAuth 2.0 est appelé flux d'attribution implicite. Il est conçu pour les applications qui accèdent aux API uniquement lorsque l'utilisateur est présent dans l'application. Ces applications ne sont pas en mesure de stocker des informations confidentielles.
Dans ce flux, votre application ouvre une URL Google qui utilise des paramètres de requête pour identifier votre application et le type d'accès à l'API dont elle a besoin. Vous pouvez ouvrir l'URL dans la fenêtre de navigateur actuelle ou dans un pop-up. L'utilisateur peut s'authentifier auprès de Google et accorder les autorisations demandées. Google redirige ensuite l'utilisateur vers votre application. La redirection inclut un jeton d'accès que votre application vérifie, puis utilise pour effectuer des requêtes d'API.
Bibliothèque cliente des API Google et services d'identité Google
Si vous utilisez la bibliothèque cliente des API Google pour JavaScript pour effectuer des appels autorisés à Google, vous devez utiliser la bibliothèque JavaScript Google Identity Services pour gérer le flux OAuth 2.0. Veuillez consulter le modèle de jeton de Google Identity Services, qui est basé sur le flux d'octroi implicite OAuth 2.0.
Prérequis
Activer les API pour votre projet.
Toute application qui appelle des API Google doit activer ces API dans API Console.
Pour activer une API pour votre projet :
- Open the API Library dans le Google API Console.
- If prompted, select a project, or create a new one.
- Utilisez la page "Bibliothèque" pour rechercher et activer les API YouTube Analytics et YouTube Reporting. De nombreuses applications qui récupèrent des données YouTube Analytics interagissent également avec l'API YouTube Data. Recherchez les autres API que votre application utilisera et activez-les é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.
- Go to the Credentials page.
- Cliquez sur Créer un client.
- Sélectionnez le type d'application Application Web.
- Remplissez le formulaire. Les applications qui utilisent JavaScript pour envoyer des requêtes autorisées aux API Google doivent spécifier des origines JavaScript autorisées. Les origines identifient les domaines à partir desquels votre application peut envoyer des requêtes au serveur OAuth 2.0. Ces origines doivent respecter les règles de validation de Google.
Identifier les niveaux d'accès
Les niveaux d'accès permettent à votre application de demander uniquement l'accès aux ressources dont elle a besoin, tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils accordent à votre application. Il peut donc exister une relation inverse entre le nombre de niveaux d'accès demandés et la probabilité d'obtenir le consentement de l'utilisateur.
Avant de commencer la mise en œuvre de l'autorisation OAuth 2.0, nous vous recommandons d'identifier les champs d'application pour lesquels votre application aura besoin d'une autorisation d'accès.
L'API YouTube Analytics utilise les champs d'application suivants :
| Champ d'application | Description |
|---|---|
https://www. |
Gérez votre compte YouTube |
https://www. |
Affichez votre compte YouTube |
https://www. |
Consultez et gérez vos éléments et le contenu associé sur YouTube. |
https://www. |
Afficher les rapports monétaires et non monétaires YouTube Analytics concernant votre contenu YouTube |
https://www. |
Affichez les rapports YouTube Analytics sur le contenu YouTube. |
L'API YouTube Reporting utilise les champs d'application suivants :
| Champ d'application | Description |
|---|---|
https://www. |
Afficher les rapports monétaires et non monétaires YouTube Analytics concernant votre contenu YouTube |
https://www. |
Affichez les rapports YouTube Analytics sur le contenu YouTube. |
Le document Champs d'application de l'API OAuth 2.0 contient la liste complète des champs d'application que vous pouvez utiliser pour accéder aux API Google.
Obtenir des jetons d'accès OAuth 2.0
Les étapes suivantes montrent comment votre application interagit avec le serveur OAuth 2.0 de Google pour obtenir le consentement d'un utilisateur afin d'effectuer une requête d'API en son nom. Votre application doit obtenir ce consentement avant de pouvoir exécuter une requête d'API Google nécessitant l'autorisation de l'utilisateur.
Étape 1 : Redirigez l'utilisateur vers le serveur OAuth 2.0 de Google
Pour demander l'autorisation d'accéder aux données d'un utilisateur, redirigez-le vers le serveur OAuth 2.0 de Google.
Points de terminaison OAuth 2.0
Générez une URL pour demander l'accès au point de terminaison OAuth 2.0 de Google à l'adresse https://accounts.google.com/o/oauth2/v2/auth. Ce point de terminaison est accessible via HTTPS. Les connexions HTTP simples sont refusées.
Le serveur d'autorisation Google est compatible avec les paramètres de chaîne de requête suivants pour les applications de serveur Web :
| Paramètres | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
client_id |
Obligatoire
ID client de votre application. Vous trouverez cette valeur dans le . |
||||||||||||||||||
redirect_uri |
Obligatoire
Détermine l'emplacement vers lequel le serveur d'API redirige l'utilisateur une fois qu'il a terminé le flux d'autorisation. La valeur doit correspondre exactement à l'un des URI de redirection autorisés pour le client OAuth 2.0 que vous avez configuré dans le de votre client . Si cette valeur ne correspond pas à un URI de redirection autorisé pour le Notez que le schéma |
||||||||||||||||||
response_type |
Obligatoire
Les applications JavaScript doivent définir la valeur du paramètre sur |
||||||||||||||||||
scope |
Obligatoire
Liste des champs d'application séparés par des espaces qui identifient les ressources auxquelles votre application peut accéder pour le compte de l'utilisateur. Ces valeurs informent l'écran de consentement que Google affiche à l'utilisateur. Les niveaux d'accès permettent à votre application de demander uniquement l'accès aux ressources dont elle a besoin, tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils accordent à votre application. Il existe donc une relation inverse entre le nombre de niveaux d'accès demandés et la probabilité d'obtenir le consentement de l'utilisateur. L'API YouTube Analytics utilise les champs d'application suivants :
L'API YouTube Reporting utilise les champs d'application suivants :
Le document Champs d'application de l'API OAuth 2.0 fournit la liste complète des champs d'application que vous pouvez utiliser pour accéder aux API Google. Nous vous recommandons de demander l'accès aux niveaux d'autorisation dans le contexte de votre application chaque fois que possible. En demandant l'accès aux données utilisateur en contexte, via l'autorisation incrémentielle, vous aidez les utilisateurs à mieux comprendre pourquoi votre application a besoin de l'accès qu'elle demande. |
||||||||||||||||||
state |
Recommandé
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 sous la forme d'une paire Vous pouvez utiliser ce paramètre à plusieurs fins, par exemple pour rediriger l'utilisateur vers la ressource appropriée dans votre application, envoyer des nonces et atténuer la falsification des requêtes intersites. Étant donné que votre |
||||||||||||||||||
include_granted_scopes |
Optional
Permet aux applications d'utiliser l'autorisation incrémentielle pour demander l'accès à des champs d'application supplémentaires dans le contexte. Si vous définissez la valeur de ce paramètre sur |
||||||||||||||||||
enable_granular_consent |
Optional
La valeur par défaut est Lorsque Google activera les autorisations précises pour une application, ce paramètre n'aura plus aucun effet. |
||||||||||||||||||
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 d'adresse e-mail dans le formulaire de connexion, soit en sélectionnant la session de connexion multiple appropriée. Définissez la valeur du paramètre sur une adresse e-mail ou un identifiant |
||||||||||||||||||
prompt |
Optional
Liste d'invites à présenter à l'utilisateur, délimitées par des espaces et sensibles à la casse. Si vous ne spécifiez pas ce paramètre, l'utilisateur ne sera invité qu'à la première demande d'accès de votre projet. Pour en savoir plus, consultez Demander un nouveau consentement. Les valeurs possibles sont :
|
||||||||||||||||||
Exemple de redirection vers le serveur d'autorisation de Google
L'exemple d'URL ci-dessous demande un accès hors connexion (access_type=offline) à un champ d'application qui permet de récupérer les rapports YouTube Analytics de l'utilisateur. Il utilise l'autorisation incrémentielle pour s'assurer que le nouveau jeton d'accès couvre tous les niveaux d'accès auxquels l'utilisateur a précédemment accordé l'accès à l'application. L'URL définit également les valeurs des paramètres obligatoires redirect_uri, response_type et client_id, ainsi que celles du paramètre state. L'URL contient des sauts de ligne et des espaces pour des raisons de lisibilité.
https://accounts.google.com/o/oauth2/v2/auth?
scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly&
include_granted_scopes=true&
state=state_parameter_passthrough_value&
redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback&
response_type=token&
client_id=client_idUne fois l'URL de la requête créée, redirigez l'utilisateur vers celle-ci.
Exemple de code JavaScript
L'extrait de code JavaScript suivant montre comment lancer le flux d'autorisation en JavaScript sans utiliser la bibliothèque cliente des API Google pour JavaScript. Étant donné que ce point de terminaison OAuth 2.0 ne prend pas en charge le partage des ressources entre origines multiples (CORS), l'extrait crée un formulaire qui ouvre la requête à ce point de terminaison.
/* * Create form to request access token from Google's OAuth 2.0 server. */ function oauthSignIn() { // Google's OAuth 2.0 endpoint for requesting an access token var oauth2Endpoint = 'https://accounts.google.com/o/oauth2/v2/auth'; // Create <form> element to submit parameters to OAuth 2.0 endpoint. var form = document.createElement('form'); form.setAttribute('method', 'GET'); // Send as a GET request. form.setAttribute('action', oauth2Endpoint); // Parameters to pass to OAuth 2.0 endpoint. var params = {'client_id': 'YOUR_CLIENT_ID', 'redirect_uri': 'YOUR_REDIRECT_URI', 'response_type': 'token', 'scope': 'https://www.googleapis.com/auth/yt-analytics.readonly https://www.googleapis.com/auth/calendar.readonly', 'include_granted_scopes': 'true', 'state': 'pass-through value'}; // Add form parameters as hidden input values. for (var p in params) { var input = document.createElement('input'); input.setAttribute('type', 'hidden'); input.setAttribute('name', p); input.setAttribute('value', params[p]); form.appendChild(input); } // Add form to page and submit it to open the OAuth 2.0 endpoint. document.body.appendChild(form); form.submit(); }
Étape 2 : Google demande le consentement de l'utilisateur
Au cours de cette étape, l'utilisateur décide d'accorder ou non à votre application l'accès demandé. À cette étape, Google affiche une fenêtre de consentement indiquant le nom de votre application et les services de l'API Google auxquels il demande l'autorisation d'accéder à l'aide des identifiants de l'utilisateur, ainsi qu'un récapitulatif des niveaux d'accès à accorder. L'utilisateur peut alors accepter d'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 du serveur OAuth 2.0 de Google indiquant si un accès a été accordé. Cette réponse est expliquée à l'étape suivante.
Erreurs
Les requêtes envoyées au point de terminaison d'autorisation OAuth 2.0 de Google peuvent afficher des messages d'erreur destinés aux utilisateurs au lieu des flux d'authentification et d'autorisation attendus. Vous trouverez ci-dessous les codes d'erreur courants et les solutions suggérées.
admin_policy_enforced
Le compte Google ne peut pas autoriser un ou plusieurs des niveaux d'accès demandés en raison des règles de son administrateur 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 aux niveaux d'accès sensibles et restreints jusqu'à ce que l'accès soit explicitement accordé à votre ID client OAuth, consultez l'article d'aide pour les administrateurs Google Workspace Contrôler quelles applications tierces et internes ont accès aux données Google Workspace.
disallowed_useragent
Le point de terminaison d'autorisation s'affiche dans un agent utilisateur intégré non autorisé par les Règles OAuth 2.0 de Google.
Android
Les développeurs Android peuvent rencontrer ce message d'erreur lorsqu'ils ouvrent des 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 AppAuth pour Android de l'OpenID Foundation.
Les développeurs Web peuvent rencontrer cette erreur lorsqu'une application Android ouvre un lien Web général dans un user-agent intégré et qu'un utilisateur accède au point de terminaison d'autorisation OAuth 2.0 de Google depuis votre site. Les développeurs doivent autoriser l'ouverture des liens généraux dans le gestionnaire de liens par défaut du système d'exploitation, qui inclut les gestionnaires de liens d'application Android ou l'application de navigateur par défaut. La bibliothèque Android Custom Tabs est également une option compatible.
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 AppAuth pour iOS de l'OpenID Foundation.
Les développeurs Web peuvent rencontrer cette erreur lorsqu'une application iOS ou macOS ouvre un lien Web général dans un user-agent intégré et qu'un utilisateur accède au point de terminaison d'autorisation OAuth 2.0 de Google depuis votre site. Les développeurs doivent autoriser l'ouverture des liens généraux dans le gestionnaire de liens par défaut du système d'exploitation, qui inclut les gestionnaires de liens universels ou l'application de navigateur par défaut. La bibliothèque SFSafariViewController est également une option compatible.
org_internal
L'ID client OAuth de la requête fait partie d'un projet limitant l'accès aux comptes Google dans une organisation Google Cloud spécifique. Pour en savoir plus sur cette option de configuration, consultez la section Type d'utilisateur de l'article d'aide "Configurer votre écran de consentement OAuth".
invalid_client
L'origine à partir de laquelle la demande a été effectuée n'est pas autorisée pour ce client. Consultez origin_mismatch.
deleted_client
Le client OAuth utilisé pour effectuer la requête a été supprimé. La suppression peut être manuelle ou automatique dans le cas de clients inutilisés . Les clients supprimés peuvent être restaurés dans les 30 jours suivant leur suppression. En savoir plus
invalid_grant
Lorsque vous utilisez l'autorisation incrémentielle, il est possible que le jeton ait expiré ou ait été invalidé. Réauthentifiez l'utilisateur et demandez-lui son consentement pour obtenir de nouveaux jetons. Si cette erreur persiste, assurez-vous que votre application a été correctement configurée et que vous utilisez les jetons et paramètres appropriés dans votre demande. Sinon, il est possible que le compte utilisateur ait été supprimé ou désactivé.
origin_mismatch
Il est possible que le schéma, le domaine et/ou le port du code JavaScript à l'origine de la demande d'autorisation ne correspondent pas à un URI d'origine JavaScript autorisé enregistré pour l'ID client OAuth. Passez en revue les origines JavaScript autorisées dans .
redirect_uri_mismatch
Le redirect_uri transmis dans la demande d'autorisation ne correspond pas à un URI de redirection autorisé pour l'ID client OAuth. Examinez les URI de redirection autorisés dans
.
Il est possible que le schéma, le domaine et/ou le port du code JavaScript à l'origine de la demande d'autorisation ne correspondent pas à un URI d'origine JavaScript autorisé enregistré pour l'ID client OAuth. Passez en revue les origines JavaScript autorisées dans .
Le paramètre redirect_uri peut faire référence au flux OAuth hors bande (OOB) qui a été abandonné et n'est plus compatible. Consultez le guide de migration pour mettre à jour votre intégration.
invalid_request
Un problème est survenu lors du traitement de votre demande. Plusieurs raisons peuvent expliquer ce problème :
- La demande n'était pas correctement formatée
- Il manquait des paramètres obligatoires dans la requête.
- La requête utilise une méthode d'autorisation non acceptée par Google. Vérifiez que votre intégration OAuth utilise une méthode d'intégration recommandée.
Étape 3 : Gérez la réponse du serveur OAuth 2.0
Points de terminaison OAuth 2.0
Le serveur OAuth 2.0 envoie une réponse à l'redirect_uri spécifié dans votre demande de jeton d'accès.
Si l'utilisateur approuve la demande, la réponse contient un jeton d'accès. Si l'utilisateur n'approuve pas la requête, la réponse contient un message d'erreur. Le jeton d'accès ou le message d'erreur sont renvoyés dans le fragment de hachage de l'URI de redirection, comme indiqué ci-dessous :
Réponse du jeton d'accès :
https://oauth2.example.com/callback#access_token=4/P7q7W91&token_type=Bearer&expires_in=3600
En plus du paramètre
access_token, la chaîne de fragment contient également le paramètretoken_type, qui est toujours défini surBearer, et le paramètreexpires_in, qui spécifie la durée de vie du jeton, en secondes. Si le paramètrestatea été spécifié dans la demande de jeton d'accès, sa valeur est également incluse dans la réponse.- Réponse d'erreur :
https://oauth2.example.com/callback#error=access_denied
Exemple de réponse du serveur OAuth 2.0
Vous pouvez tester ce flux en cliquant sur l'URL exemple suivante, qui demande un accès en lecture seule pour afficher les métadonnées des fichiers dans votre Google Drive et un accès en lecture seule pour afficher vos événements Google Agenda :
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyt-analytics.readonly& include_granted_scopes=true& state=state_parameter_passthrough_value& redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback& response_type=token& client_id=client_id
Une fois le flux OAuth 2.0 terminé, vous serez redirigé vers http://localhost/oauth2callback. Cette URL générera une erreur 404 NOT FOUND, sauf si votre machine locale sert un fichier à cette adresse. L'étape suivante fournit plus de détails sur les informations renvoyées dans l'URI lorsque l'utilisateur est redirigé vers votre application.
Étape 4 : Vérifiez les habilitations accordées par les utilisateurs
Lorsque vous demandez plusieurs autorisations (habilitations), il est possible que les utilisateurs n'accordent pas à votre application l'accès à toutes. Votre application doit vérifier les champs d'application qui ont été accordés et gérer correctement les situations où certaines autorisations sont refusées, généralement en désactivant les fonctionnalités qui dépendent de ces champs d'application refusés.
Il existe toutefois des exceptions. Les applications Google Workspace Enterprise avec délégation d'autorité au niveau du domaine ou les applications marquées comme fiables contournent l'écran de consentement pour les autorisations précises. Pour ces applications, les utilisateurs ne verront pas l'écran de consentement pour les autorisations précises. Votre application recevra tous les niveaux d'accès demandés ou aucun.
Pour en savoir plus, consultez Gérer les autorisations précises.
Points de terminaison OAuth 2.0
Pour vérifier si l'utilisateur a accordé à votre application l'accès à un champ particulier, examinez le champ scope dans la réponse du jeton d'accès. Champs d'application de l'accès accordé par le jeton d'accès, exprimés sous la forme d'une liste de chaînes sensibles à la casse et délimitées par des espaces.
Par exemple, l'exemple de réponse de jeton d'accès suivant indique que l'utilisateur a accordé à votre application l'accès aux autorisations d'activité Drive et d'événements Agenda en lecture seule :
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/yt-analytics.readonly https://www.googleapis.com/auth/calendar.readonly", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
Appeler des API Google
Points de terminaison OAuth 2.0
Une fois que votre application a obtenu un jeton d'accès, vous pouvez l'utiliser pour effectuer des appels à une API Google au nom d'un compte utilisateur donné si le ou 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 envoyée à l'API en incluant un paramètre de requête access_token ou une valeur d'en-tête HTTP Authorization Bearer. Dans la mesure du possible, 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 vous appelez l'API YouTube Analytics).
Notez que l'API YouTube Analytics n'est pas compatible avec le flux de compte de service. L'API YouTube Reporting n'est compatible avec les comptes de service que pour les propriétaires de contenu YouTube qui possèdent et gèrent plusieurs chaînes YouTube, comme les maisons de disques et les studios de cinéma.
Vous pouvez tester toutes les API Google et afficher leurs habilitations sur la page OAuth 2.0 Playground.
Exemples de requêtes HTTP GET
Un appel au point de terminaison
reports.query (API YouTube Analytics) à l'aide de l'en-tête HTTP Authorization: Bearer peut ressembler à ce qui suit. Notez que vous devez spécifier votre propre jeton d'accès :
GET /youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views 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 paramètre de chaîne de requête access_token :
GET https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views
curl exemples
Vous pouvez tester ces commandes avec l'application en ligne de commande curl. Voici un exemple qui utilise l'option d'en-tête HTTP (méthode recommandée) :
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views
Vous pouvez également utiliser l'option de paramètre de chaîne de requête :
curl https://www.googleapis.com/youtube/analytics/v1/reports?access_token=access_token&ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views
Exemple de code JavaScript
L'extrait de code ci-dessous montre comment utiliser CORS (Cross-origin resource sharing) pour envoyer une requête à une API Google. Cet exemple n'utilise pas la bibliothèque cliente des API Google pour JavaScript. Toutefois, même si vous n'utilisez pas la bibliothèque cliente, le guide sur la compatibilité CORS dans la documentation de cette bibliothèque vous aidera probablement à mieux comprendre ces requêtes.
Dans cet extrait de code, la variable access_token représente le jeton que vous avez obtenu pour effectuer des requêtes d'API au nom de l'utilisateur autorisé. L'exemple complet montre comment stocker ce jeton dans le stockage local du navigateur et le récupérer lors de l'envoi d'une requête API.
var xhr = new XMLHttpRequest(); xhr.open('GET', 'https://www.googleapis.com/youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views&' + 'access_token=' + params['access_token']); xhr.onreadystatechange = function (e) { console.log(xhr.response); }; xhr.send(null);
Exemple complet
Points de terminaison OAuth 2.0
Cet exemple de code montre comment effectuer le flux OAuth 2.0 en JavaScript sans utiliser la bibliothèque cliente des API Google pour JavaScript. Le code correspond à une page HTML qui affiche un bouton permettant d'essayer une requête API. Si vous cliquez sur le bouton, le code vérifie si la page a stocké un jeton d'accès à l'API dans le stockage local de votre navigateur. Si c'est le cas, il exécute la requête API. Sinon, il lance le flux OAuth 2.0.
Pour le flux OAuth 2.0, la page suit les étapes suivantes :
- Il redirige l'utilisateur vers le serveur OAuth 2.0 de Google, qui demande l'accès aux habilitations
https://www.googleapis.com/auth/yt-analytics.readonlyethttps://www.googleapis.com/auth/calendar.readonly. - Après avoir accordé (ou refusé) l'accès à un ou plusieurs des niveaux d'accès demandés, l'utilisateur est redirigé vers la page d'origine, qui analyse le jeton d'accès à partir de la chaîne de l'identifiant de fragment.
- La page vérifie les habilitations que l'utilisateur a accordées à l'application.
Si l'utilisateur a accordé l'accès aux portées demandées, la page utilise le jeton d'accès pour effectuer la requête d'API exemple.
Cette requête d'API appelle la méthode
reports.queryde l'API YouTube Analytics pour récupérer le nombre de vues de la chaîne YouTube de l'utilisateur autorisé.- Si la requête s'exécute correctement, la réponse de l'API est consignée dans la console de débogage du navigateur.
Vous pouvez révoquer l'accès à l'application sur la page Autorisations de votre compte Google. L'application sera listée sous le nom OAuth 2.0 Demo for Google API Docs.
Pour exécuter ce code localement, vous devez définir des valeurs pour les variables YOUR_CLIENT_ID et YOUR_REDIRECT_URI qui correspondent à vos identifiants d'autorisation. La variable YOUR_REDIRECT_URI doit être définie sur l'URL à laquelle la page est diffusée. La valeur doit correspondre exactement à l'un des URI de redirection autorisés pour le client OAuth 2.0, que vous avez configuré dans
. Si cette valeur ne correspond pas à un URI autorisé, une erreur redirect_uri_mismatch s'affiche. L'API appropriée doit également être activée pour votre projet.
<html><head></head><body>
<script>
var YOUR_CLIENT_ID = 'REPLACE_THIS_VALUE';
var YOUR_REDIRECT_URI = 'REPLACE_THIS_VALUE';
// Parse query string to see if page request is coming from OAuth 2.0 server.
var fragmentString = location.hash.substring(1);
var params = {};
var regex = /([^&=]+)=([^&]*)/g, m;
while (m = regex.exec(fragmentString)) {
params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
}
if (Object.keys(params).length > 0 && params['state']) {
if (params['state'] == localStorage.getItem('state')) {
localStorage.setItem('oauth2-test-params', JSON.stringify(params) );
trySampleRequest();
} else {
console.log('State mismatch. Possible CSRF attack');
}
}
// Function to generate a random state value
function generateCryptoRandomState() {
const randomValues = new Uint32Array(2);
window.crypto.getRandomValues(randomValues);
// Encode as UTF-8
const utf8Encoder = new TextEncoder();
const utf8Array = utf8Encoder.encode(
String.fromCharCode.apply(null, randomValues)
);
// Base64 encode the UTF-8 data
return btoa(String.fromCharCode.apply(null, utf8Array))
.replace(/\+/g, '-')
.replace(/\//g, '_')
.replace(/=+$/, '');
}
// If there's an access token, try an API request.
// Otherwise, start OAuth 2.0 flow.
function trySampleRequest() {
var params = JSON.parse(localStorage.getItem('oauth2-test-params'));
if (params && params['access_token']) {
// User authorized the request. Now, check which scopes were granted.
if (params['scope'].includes('https://www.googleapis.com/auth/drive.metadata.readonly')) {
// User authorized read-only Drive activity permission.
// Calling the APIs, etc.
var xhr = new XMLHttpRequest();
xhr.open('GET',
'https://www.googleapis.com/youtube/analytics/v1/reports?ids=channel%3D%3DMINE&start-date=2016-05-01&end-date=2016-06-30&metrics=views&' +
'access_token=' + params['access_token']);
xhr.onreadystatechange = function (e) {
if (xhr.readyState === 4 && xhr.status === 200) {
console.log(xhr.response);
} else if (xhr.readyState === 4 && xhr.status === 401) {
// Token invalid, so prompt for user permission.
oauth2SignIn();
}
};
xhr.send(null);
}
else {
// User didn't authorize read-only Drive activity permission.
// Update UX and application accordingly
console.log('User did not authorize read-only Drive activity permission.');
}
// Check if user authorized Calendar read permission.
if (params['scope'].includes('https://www.googleapis.com/auth/calendar.readonly')) {
// User authorized Calendar read permission.
// Calling the APIs, etc.
console.log('User authorized Calendar read permission.');
}
else {
// User didn't authorize Calendar read permission.
// Update UX and application accordingly
console.log('User did not authorize Calendar read permission.');
}
} else {
oauth2SignIn();
}
}
/*
* Create form to request access token from Google's OAuth 2.0 server.
*/
function oauth2SignIn() {
// create random state value and store in local storage
var state = generateCryptoRandomState();
localStorage.setItem('state', state);
// Google's OAuth 2.0 endpoint for requesting an access token
var oauth2Endpoint = 'https://accounts.google.com/o/oauth2/v2/auth';
// Create element to open OAuth 2.0 endpoint in new window.
var form = document.createElement('form');
form.setAttribute('method', 'GET'); // Send as a GET request.
form.setAttribute('action', oauth2Endpoint);
// Parameters to pass to OAuth 2.0 endpoint.
var params = {'client_id': YOUR_CLIENT_ID,
'redirect_uri': YOUR_REDIRECT_URI,
'scope': 'https://www.googleapis.com/auth/yt-analytics.readonly https://www.googleapis.com/auth/calendar.readonly',
'state': state,
'include_granted_scopes': 'true',
'response_type': 'token'};
// Add form parameters as hidden input values.
for (var p in params) {
var input = document.createElement('input');
input.setAttribute('type', 'hidden');
input.setAttribute('name', p);
input.setAttribute('value', params[p]);
form.appendChild(input);
}
// Add form to page and submit it to open the OAuth 2.0 endpoint.
document.body.appendChild(form);
form.submit();
}
</script>
<button onclick="trySampleRequest();">Try sample request</button>
</body></html>Règles de validation des origines JavaScript
Google applique les règles de validation suivantes aux origines JavaScript pour aider les développeurs à sécuriser leurs applications. Vos origines JavaScript doivent respecter ces règles. Pour connaître la définition des termes "domaine", "hôte" et "schéma" mentionnés ci-dessous, consultez la section 3 de la norme RFC 3986.
| Règles de validation | |
|---|---|
| Schéma |
Les origines JavaScript doivent utiliser le schéma HTTPS, et non HTTP. Les URI localhost (y compris les URI d'adresse IP localhost) sont exemptés de cette règle. |
| Hôte |
Les hôtes ne peuvent pas être des adresses IP brutes. Les adresses IP localhost sont exemptées de cette règle. |
| Domaine |
“googleusercontent.com”.goo.gl), sauf si l'application est propriétaire du domaine. |
| Userinfo |
Les origines JavaScript ne peuvent pas contenir le sous-composant userinfo. |
| Chemin d'accès |
Les origines JavaScript ne peuvent pas contenir le composant de chemin d'accès. |
| Query |
Les origines JavaScript ne peuvent pas contenir le composant de requête. |
| Fragment |
Les origines JavaScript ne peuvent pas contenir le composant de fragment. |
| Caractères |
Les origines JavaScript ne peuvent pas contenir certains caractères, y compris :
|
Autorisation incrémentielle
Dans le protocole OAuth 2.0, votre application demande l'autorisation d'accéder à des ressources, qui sont identifiées par des champs d'application. Pour une expérience utilisateur optimale, il est recommandé de demander l'autorisation d'accéder aux ressources au moment où vous en avez besoin. Pour permettre cette pratique, le serveur d'autorisation de Google est compatible avec l'autorisation incrémentielle. Cette fonctionnalité vous permet de demander des niveaux d'accès selon les besoins et, si l'utilisateur accorde l'autorisation pour le nouveau niveau d'accès, renvoie un code d'autorisation qui peut être échangé contre un jeton contenant tous les niveaux d'accès que l'utilisateur a accordés au projet.
Par exemple, supposons qu'une application récupère des rapports YouTube Analytics, dont certains sont des rapports monétaires qui nécessitent l'accès à un champ d'application supplémentaire qui n'est pas nécessaire pour les autres rapports. Dans ce cas, au moment de la connexion, l'application ne peut demander l'accès qu'au champ d'application https://www.googleapis.com/auth/yt-analytics.readonly.
Toutefois, si l'utilisateur a tenté de récupérer un rapport monétaire, l'application peut également demander l'accès au champ d'application https://www.googleapis.com/auth/yt-analytics-monetary.readonly.
Les règles suivantes s'appliquent à un jeton d'accès obtenu à partir d'une autorisation incrémentielle :
- Le jeton peut être utilisé pour accéder aux ressources correspondant à l'un des niveaux d'accès inclus dans la nouvelle autorisation combinée.
- Lorsque vous utilisez le jeton d'actualisation pour l'autorisation combinée afin d'obtenir un jeton d'accès, ce jeton représente l'autorisation combinée et peut être utilisé pour n'importe quelle valeur
scopeincluse dans la réponse. - L'autorisation combinée inclut tous les niveaux d'accès que l'utilisateur a accordés au projet d'API, même si les autorisations ont été demandées par différents clients. Par exemple, si un utilisateur a accordé l'accès à un champ d'application à l'aide du client de bureau d'une application, puis a accordé un autre champ d'application à la même application à l'aide d'un client mobile, l'autorisation combinée inclura les deux champs d'application.
- Si vous révoquez un jeton représentant une autorisation combinée, l'accès à tous les niveaux d'autorisation au nom de l'utilisateur associé est révoqué simultanément.
Les exemples de code ci-dessous montrent comment ajouter des autorisations à un jeton d'accès existant. Cette approche permet à votre application d'éviter d'avoir à gérer plusieurs jetons d'accès.
Points de terminaison OAuth 2.0
Dans cet exemple, l'application appelante demande l'accès pour récupérer les données YouTube Analytics de l'utilisateur, en plus de tout autre accès que l'utilisateur a déjà accordé à l'application.
Pour ajouter des habilitations à un jeton d'accès existant, incluez le paramètre include_granted_scopes dans votre requête au serveur OAuth 2.0 de Google.
L'extrait de code suivant montre comment procéder. L'extrait suppose que vous avez stocké les niveaux d'accès pour lesquels votre jeton d'accès est valide dans l'espace de stockage local du navigateur. (Le code de l'exemple complet stocke une liste de champs d'application pour lesquels le jeton d'accès est valide en définissant la propriété oauth2-test-params.scope dans le stockage local du navigateur.)
L'extrait compare les niveaux d'accès pour lesquels le jeton d'accès est valide au niveau d'accès que vous souhaitez utiliser pour une requête spécifique. Si le jeton d'accès ne couvre pas ce champ d'application, le flux OAuth 2.0 démarre.
Ici, la fonction oauth2SignIn est identique à celle fournie à l'étape 2 (et qui est fournie plus loin dans l'exemple complet).
var SCOPE = 'https://www.googleapis.com/auth/yt-analytics.readonly'; var params = JSON.parse(localStorage.getItem('oauth2-test-params')); var current_scope_granted = false; if (params.hasOwnProperty('scope')) { var scopes = params['scope'].split(' '); for (var s = 0; s < scopes.length; s++) { if (SCOPE == scopes[s]) { current_scope_granted = true; } } } if (!current_scope_granted) { oauth2SignIn(); // This function is defined elsewhere in this document. } else { // Since you already have access, you can proceed with the API request. }
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 aux paramètres de son compte. Pour en savoir plus, consultez la section Supprimer l'accès d'un site ou d'une application du document d'aide Applications et sites tiers ayant accès à votre compte.
Il est également possible pour une application de révoquer de manière programmatique l'accès qui lui a été accordé. La révocation programmatique est importante dans les cas où un utilisateur se désabonne, supprime une application ou lorsque les ressources d'API requises par une application ont considérablement changé. En d'autres termes, une partie du processus de suppression peut inclure une requête d'API pour s'assurer que les autorisations précédemment accordées à l'application sont supprimées.
Points de terminaison OAuth 2.0
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 un jeton d'actualisation correspondant, ce dernier 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. En cas d'erreur, un code d'état HTTP 400 est renvoyé avec un code d'erreur.
L'extrait de code JavaScript suivant montre comment révoquer un jeton en JavaScript sans utiliser la bibliothèque cliente des API Google pour JavaScript. Étant donné que le point de terminaison OAuth 2.0 de Google pour la révocation des jetons ne prend pas en charge le partage des ressources d'origine croisée (CORS), le code crée un formulaire et l'envoie au point de terminaison au lieu d'utiliser la méthode XMLHttpRequest() pour publier la requête.
function revokeAccess(accessToken) { // Google's OAuth 2.0 endpoint for revoking access tokens. var revokeTokenEndpoint = 'https://oauth2.googleapis.com/revoke'; // Create <form> element to use to POST data to the OAuth 2.0 endpoint. var form = document.createElement('form'); form.setAttribute('method', 'post'); form.setAttribute('action', revokeTokenEndpoint); // Add access token to the form so it is set as value of 'token' parameter. // This corresponds to the sample curl request, where the URL is: // https://oauth2.googleapis.com/revoke?token={token} var tokenField = document.createElement('input'); tokenField.setAttribute('type', 'hidden'); tokenField.setAttribute('name', 'token'); tokenField.setAttribute('value', accessToken); form.appendChild(tokenField); // Add form to page and submit it to actually revoke the token. document.body.appendChild(form); form.submit(); }
Implémenter la protection multicompte
Pour protéger les comptes de vos utilisateurs, vous devez également implémenter la protection multi-comptes en utilisant le service de protection multi-comptes de Google. Ce service vous permet de vous abonner aux notifications d'événements de sécurité, qui fournissent à votre application des informations sur les modifications majeures apportées au compte utilisateur. Vous pouvez ensuite utiliser ces informations pour prendre des mesures en fonction de la manière dont 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 multi-comptes 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
Pour en savoir plus sur l'implémentation de la protection multicompte et obtenir la liste complète des événements disponibles, consultez la page Protéger les comptes utilisateur avec la protection multicompte .