Ce document explique comment mettre en œuvre l'autorisation OAuth 2.0 pour accéder aux API Google à partir d'une application Web JavaScript. OAuth 2.0 permet aux utilisateurs de partager des données spécifiques avec une application tout en préservant la confidentialité de leurs noms d'utilisateur, mots de passe et autres informations. Par exemple, une application peut utiliser OAuth 2.0 pour obtenir l'autorisation des utilisateurs pour stocker des fichiers dans Google Drive.
Ce flux OAuth 2.0 est appelé flux d'attribution implicite. Il est conçu pour les applications qui n'accèdent aux API que 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 les paramètres de requête pour identifier votre application et le type d'accès à l'API requis. Vous pouvez l'ouvrir dans la fenêtre actuelle de votre navigateur 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 valide, puis utilise pour envoyer des requêtes API.
Bibliothèque cliente des API Google et Google Identity Services
Si vous utilisez la bibliothèque cliente des API Google pour JavaScript afin d'effectuer des appels autorisés à Google, vous devez utiliser la bibliothèque JavaScript des services Google Identity pour gérer le flux OAuth 2.0. Veuillez consulter le modèle de jeton des services Google Identity, qui est basé sur le flux implicite OAuth 2.0.
Prérequis
Activer les API pour votre projet.
Toute application qui appelle les API Google doit les activer dans le API Console.
Pour activer une API pour votre projet:
- Open the API Library dans Google API Console.
- If prompted, select a project, or create a new one.
- L'API API Library répertorie toutes les API disponibles, regroupées par famille et par popularité. Si l'API que vous souhaitez activer n'apparaît pas dans la liste, utilisez la fonctionnalité de recherche pour la trouver ou cliquez sur Tout afficher dans la famille de produits à laquelle elle 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 sur le serveur OAuth 2.0 de Google. Les étapes suivantes expliquent comment créer des identifiants pour votre projet. Vos applications peuvent ensuite utiliser les identifiants pour accéder aux API que vous avez activées pour ce projet.
- Go to the Credentials page.
- Cliquez sur Créer des identifiants > ID client OAuth.
- Sélectionnez le type d'application Web.
- Remplissez le formulaire. Les applications qui utilisent JavaScript pour envoyer des requêtes API Google autorisées 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. Elles permettent également aux utilisateurs de contrôler le niveau d'accès qu'ils accordent à votre application. Par conséquent, il peut y avoir une relation inverse entre le nombre de champs d'application demandés et la probabilité d'obtenir le consentement de l'utilisateur.
Avant de commencer à mettre en œuvre l'autorisation OAuth 2.0, nous vous recommandons d'identifier les champs d'application pour lesquels votre application aura besoin d'une autorisation.
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 API en son nom. Votre application doit disposer de ce consentement pour pouvoir exécuter une requête API Google nécessitant l'autorisation de l'utilisateur.
Étape 1: Redirection 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 de Google accepte 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 l' Credentials page API Console. |
||||||
redirect_uri |
Obligatoire
Détermine où 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 fichier API Console
Credentials pagede votre client. Si cette valeur ne correspond pas à un URI de redirection autorisé pour l'élément Notez que le schéma, la casse et la barre oblique finale (" |
||||||
response_type |
Obligatoire
Les applications JavaScript doivent définir la valeur du paramètre sur |
||||||
scope |
Obligatoire
Liste de champs d'application délimités par des espaces qui identifient les ressources auxquelles votre application pourrait accéder au nom de l'utilisateur. Ces valeurs informent l'écran de consentement que Google affiche à l'utilisateur. Les champs d'application permettent à votre application de demander uniquement l'accès aux ressources dont elle a besoin. Elles permettent également aux utilisateurs de contrôler le niveau d'accès accordé à votre application. Par conséquent, il existe une relation inverse entre le nombre de champs d'application demandés et la probabilité d'obtenir le consentement de l'utilisateur. Dans la mesure du possible, il est recommandé que votre application demande l'accès aux champs d'application des autorisations en contexte. En demandant l'accès aux données utilisateur en contexte, via l'autorisation incrémentielle, vous aidez les utilisateurs à comprendre plus facilement pourquoi votre application a besoin de l'accès qu'elle demande. |
||||||
state |
Recommandé
Spécifie toute valeur de chaîne utilisée par votre application pour conserver l'état entre votre requête d'autorisation et la réponse du serveur d'autorisation.
Le serveur renvoie la valeur exacte que vous envoyez en tant que paire Vous pouvez utiliser ce paramètre à différentes fins, par exemple pour rediriger l'utilisateur vers la ressource appropriée dans votre application, pour envoyer des nonces et pour atténuer les contrefaçons de 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 en contexte. Si vous définissez la valeur de ce paramètre sur |
||||||
login_hint |
Optional
Si votre application sait quel utilisateur tente d'authentifier, elle peut utiliser ce paramètre pour fournir un indice au serveur d'authentification Google. Le serveur utilise cet indice pour simplifier le flux de connexion en préremplissant le champ d'adresse e-mail dans le formulaire de connexion ou en sélectionnant la session multiconnexion appropriée. Définissez la valeur du paramètre sur une adresse e-mail ou un identifiant |
||||||
prompt |
Optional
Liste d'invites sensibles à la casse et délimitées par des espaces, pour présenter l'utilisateur. Si vous ne spécifiez pas ce paramètre, l'utilisateur n'est invité que la première fois que votre projet demande l'accès. Pour en savoir plus, consultez Demander un nouveau consentement. Les valeurs possibles sont :
|
||||||
Exemple de redirection vers le serveur d'autorisation de Google
Vous trouverez ci-dessous un exemple d'URL, avec des sauts de ligne et des espaces pour une meilleure lisibilité.
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly& include_granted_scopes=true& response_type=token& state=state_parameter_passthrough_value& redirect_uri=https%3A//oauth2.example.com/code& client_id=client_id
Une fois l'URL de 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 n'est pas compatible avec le partage de ressources inter-origines (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/drive.metadata.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 à votre application l'accès demandé. À ce stade, Google affiche une fenêtre de consentement indiquant le nom de votre application et les services d'API Google auxquels elle demande l'autorisation d'accéder avec les identifiants d'autorisation de l'utilisateur, ainsi qu'un résumé des champs d'application à accorder. L'utilisateur peut ensuite autoriser 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 pour indiquer si un accès a été accordé. Cette réponse est expliquée à l'étape suivante.
Erreurs
Les requêtes envoyées au point de terminaison d'autorisation OAuth 2.0 de Google peuvent afficher des messages d'erreur visibles par l'utilisateur au lieu des flux d'authentification et d'autorisation attendus. Les codes d'erreur courants et les solutions suggérées sont indiqués ci-dessous.
admin_policy_enforced
Le compte Google ne peut pas autoriser un ou plusieurs niveaux d'accès demandés en raison des règles de leur administrateur Google Workspace. 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 afin de savoir comment l'administrateur peut restreindre l'accès à tous les champs d'application ou les champs d'application sensibles et 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 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.
Nous recommandons aux développeurs d'utiliser à la place 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 à partir de votre site. Les développeurs doivent autoriser l'ouverture des liens généraux dans le gestionnaire de liens par défaut du système d'exploitation, qui inclut à la fois les gestionnaires Android App Links ou l'application de navigateur par défaut. L'option Android Custom Tabs est également disponible.
iOS
Les développeurs iOS et macOS peuvent rencontrer cette erreur lorsqu'ils ouvrent des requêtes d'autorisation dans WKWebView.
Nous recommandons aux développeurs d'utiliser à la place 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 à partir de votre site. Les développeurs doivent autoriser l'ouverture des liens généraux dans le gestionnaire de liens par défaut du système d'exploitation, qui inclut des gestionnaires Universal Links ou l'application de navigateur par défaut. La bibliothèque SFSafariViewController est également une option compatible.
org_internal
L'ID client OAuth dans la requête fait partie d'un projet limitant l'accès aux comptes Google d'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 sur la configuration de l'écran de consentement OAuth.
invalid_client
L'origine à l'origine de la requête n'est pas autorisée pour ce client. Consultez origin_mismatch.
invalid_grant
Lors de l'autorisation incrémentielle, le jeton a expiré ou a été invalidé. Authentifiez à nouveau l'utilisateur et demandez son consentement pour obtenir de nouveaux jetons. Si vous continuez à voir cette erreur, vérifiez que votre application a été correctement configurée et que vous avez utilisé les jetons et les paramètres appropriés dans votre requête. Sinon, le compte utilisateur a peut-être été supprimé ou désactivé.
origin_mismatch
Le schéma, le domaine et/ou le port du code JavaScript à l'origine de la demande d'autorisation peuvent ne pas correspondre à un URI d'origine JavaScript autorisé enregistré pour l'ID client OAuth. Examinez les origines JavaScript autorisées dans le Google API Console Credentials page.
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 Google API Console Credentials page.
Le schéma, le domaine et/ou le port du code JavaScript à l'origine de la demande d'autorisation peuvent ne pas correspondre à un URI d'origine JavaScript autorisé enregistré pour l'ID client OAuth. Examinez les origines JavaScript autorisées dans Google API Console Credentials page.
Le paramètre redirect_uri peut faire référence au flux hors bande OAuth (OOB) obsolète et non compatible. Consultez le guide de migration pour mettre à jour votre intégration.
É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 au redirect_uri spécifié dans votre requête 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 est renvoyé sur le fragment de hachage de l'URI de redirection, comme indiqué ci-dessous:
Une réponse du jeton d'accès:
https://oauth2.example.com/callback#access_token=4/P7q7W91&token_type=Bearer&expires_in=3600
Outre le 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 requête 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'exemple d'URL suivant, qui demande un accès en lecture seule pour afficher les métadonnées des fichiers de votre Google Drive:
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly& include_granted_scopes=true& response_type=token& state=state_parameter_passthrough_value& redirect_uri=https%3A//oauth2.example.com/code& client_id=client_id
Après avoir terminé le flux OAuth 2.0, vous serez redirigé vers http://localhost/oauth2callback. Cette URL générera une erreur 404 NOT FOUND, sauf si votre ordinateur local diffuse 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.
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 appeler une API Google au nom d'un compte utilisateur donné si le ou les champs d'application 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 un paramètre de requête access_token ou une valeur Authorization d'en-tête HTTP Bearer. Dans la mesure du possible, il est préférable d'utiliser l'en-tête HTTP, car les chaînes de requête 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 Drive Files).
Vous pouvez essayer toutes les API Google et consulter leurs habilitations sur OAuth 2.0 Playground.
Exemples HTTP GET
Un appel vers le point de terminaison
drive.files (API Drive Files) avec l'en-tête HTTP Authorization: Bearer peut se présenter comme suit. Notez que vous devez spécifier votre propre jeton d'accès:
GET /drive/v2/files HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
Voici un appel vers la même API pour l'utilisateur authentifié à l'aide du paramètre de chaîne de requête access_token:
GET https://www.googleapis.com/drive/v2/files?access_token=access_token
Exemples curl
Vous pouvez tester ces commandes avec l'application de ligne de commande curl. Voici un exemple qui utilise l'option d'en-tête HTTP (recommandé):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files
Vous pouvez également utiliser le paramètre de chaîne de requête:
curl https://www.googleapis.com/drive/v2/files?access_token=access_token
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. Cependant, 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 API au nom de l'utilisateur autorisé. L'exemple complet montre comment stocker ce jeton dans l'espace de stockage local du navigateur et le récupérer lors d'une requête API.
var xhr = new XMLHttpRequest();
xhr.open('GET',
'https://www.googleapis.com/drive/v3/about?fields=user&' +
'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 parcours OAuth 2.0 en JavaScript sans utiliser la bibliothèque cliente des API Google pour JavaScript. Le code est destiné à une page HTML qui affiche un bouton pour essayer une requête API. Si vous cliquez sur ce bouton, le code vérifie si la page a stocké un jeton d'accès à l'API dans l'espace de stockage local de votre navigateur. Si tel est le cas, il exécute la requête API. Sinon, elle lance le flux OAuth 2.0.
Pour le flux OAuth 2.0, procédez comme suit:
- Il redirige l'utilisateur vers le serveur OAuth 2.0 de Google, qui demande l'accès au champ d'application
https://www.googleapis.com/auth/drive.metadata.readonly. - Après avoir accordé (ou refusé) l'accès à un ou plusieurs champs d'application demandés, l'utilisateur est redirigé vers la page d'origine, qui analyse le jeton d'accès à partir de la chaîne d'identifiant de fragment.
La page utilise le jeton d'accès pour effectuer l'exemple de requête API.
La requête API appelle la méthode
about.getde l'API Drive pour récupérer des informations sur le compte Google Drive 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 via la page Autorisations de votre compte Google. L'application est listée dans la documentation de démonstration OAuth 2.0 pour l'API Google Docs.
Pour exécuter ce code localement, vous devez définir les valeurs des variables YOUR_CLIENT_ID et YOUR_REDIRECT_URI correspondant à vos identifiants d'autorisation. La variable YOUR_REDIRECT_URI doit être définie sur l'URL sur 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 API Console Credentials page. Si cette valeur ne correspond pas à un URI autorisé, une erreur redirect_uri_mismatch s'affiche. Votre projet doit également activer l'API appropriée pour cette requête.
<html><head></head><body>
<script>
var YOUR_CLIENT_ID = 'REPLACE_THIS_VALUE';
var YOUR_REDIRECT_URI = 'REPLACE_THIS_VALUE';
var fragmentString = location.hash.substring(1);
// Parse query string to see if page request is coming from OAuth 2.0 server.
var params = {};
var regex = /([^&=]+)=([^&]*)/g, m;
while (m = regex.exec(fragmentString)) {
params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
}
if (Object.keys(params).length > 0) {
localStorage.setItem('oauth2-test-params', JSON.stringify(params) );
if (params['state'] && params['state'] == 'try_sample_request') {
trySampleRequest();
}
}
// 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']) {
var xhr = new XMLHttpRequest();
xhr.open('GET',
'https://www.googleapis.com/drive/v3/about?fields=user&' +
'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 {
oauth2SignIn();
}
}
/*
* Create form to request access token from Google's OAuth 2.0 server.
*/
function oauth2SignIn() {
// 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/drive.metadata.readonly',
'state': 'try_sample_request',
'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 de l'origine 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. Reportez-vous à la section 3 du document RFC 3986 pour obtenir la définition du domaine, de l'hôte et du schéma, comme indiqué ci-dessous.
| Règles de validation | |
|---|---|
| Schéma |
Les origines JavaScript doivent utiliser le schéma HTTPS, et non HTTP. Les URI locaux (y compris les URI d'adresses localhost) ne sont pas concernés par cette règle. |
| Hôte |
Les hôtes ne peuvent pas être des adresses IP brutes. Les adresses IP Localhost sont exclues de cette règle. |
| Domaine |
“googleusercontent.com”.goo.gl), sauf si l'application est propriétaire du domaine. |
| Informations utilisateur |
Les origines JavaScript ne peuvent pas contenir le sous-composant userinfo. |
| Chemin d'accès |
Les origines JavaScript ne peuvent pas contenir le composant du chemin. |
| Requête |
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 les suivants :
|
Autorisation incrémentielle
Dans le protocole OAuth 2.0, votre application demande l'autorisation d'accéder aux ressources, qui sont identifiées par les champs d'application. Nous vous recommandons de demander une autorisation pour les ressources que vous utilisez au moment où vous en avez besoin. Pour activer cette pratique, le serveur d'autorisation de Google est compatible avec l'autorisation incrémentielle. Cette fonctionnalité vous permet de demander des champs d'application en fonction des besoins et, si l'utilisateur accorde l'autorisation pour le nouveau champ d'application, renvoie un code d'autorisation pouvant être échangé contre un jeton contenant tous les champs d'application accordés par le projet.
Par exemple, une application qui permet aux utilisateurs d'écouter des titres musicaux et de créer des mix peut nécessiter très peu de ressources au moment de la connexion, peut-être rien de plus que le nom de la personne qui se connecte. Toutefois, pour enregistrer un mix terminé, il leur faudra accéder à Google Drive. La plupart des gens trouvent naturellement naturel s'ils n'ont été invités à accéder à leur Google Drive qu'au moment où l'application en avait réellement besoin.
Dans ce cas, au moment de la connexion, l'application peut demander aux champs d'application openid et profile d'effectuer une connexion de base, puis plus tard au champ d'application https://www.googleapis.com/auth/drive.file au moment de la première requête pour enregistrer un mix.
Les règles suivantes s'appliquent à un jeton d'accès obtenu par le biais d'une autorisation incrémentielle:
- Le jeton peut être utilisé pour accéder aux ressources correspondant à l'un des champs d'application 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, celui-ci 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 champs d'application que l'utilisateur a accordés au projet d'API, même s'ils ont été demandés 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 accordé un autre champ d'application à la même application via un client mobile, l'autorisation combinée inclut les deux champs d'application.
- Si vous révoquez un jeton représentant une autorisation combinée, l'accès à tous les champs d'application de cette autorisation au nom de l'utilisateur associé est révoqué simultanément.
Les exemples de code ci-dessous montrent comment ajouter des champs d'application à un jeton d'accès existant. Cette approche permet à votre application d'éviter de gérer plusieurs jetons d'accès.
Points de terminaison OAuth 2.0
Pour ajouter des champs d'application à un jeton d'accès existant, incluez le paramètre include_granted_scopes dans votre requête envoyée au serveur OAuth 2.0 de Google.
L'extrait de code suivant montre comment procéder. L'extrait suppose que vous avez stocké les habilitations pour lesquelles votre jeton d'accès est valide dans l'espace de stockage local du navigateur. 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 l'espace de stockage local du navigateur.
L'extrait de code compare les champs d'application pour lesquels le jeton d'accès est valide à ceux que vous souhaitez utiliser pour une requête donnée. 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 (qui est fournie plus loin dans l'exemple complet).
var SCOPE = 'https://www.googleapis.com/auth/drive.metadata.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, l'utilisateur peut révoquer l'accès accordé à une application. Il peut révoquer l'accès dans les paramètres du compte. Pour en savoir plus, consultez la section Supprimer l'accès au site ou à l'application des sites et applications tiers ayant accès à votre compte.
Une application peut également révoquer programmatiquement l'accès qui lui est attribué. La révocation programmatique est importante dans les cas où un utilisateur se désabonne, supprime une application ou a changé de manière significative les ressources API requises par une application. En d'autres termes, une partie du processus de suppression peut inclure une requête 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 programmatiquement un jeton, 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}
Le jeton peut être un jeton d'accès ou un jeton d'actualisation. Si le jeton est un jeton d'accès et qu'il possède un jeton d'actualisation correspondant, il est également révoqué.
Si la révocation a 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 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 n'est pas compatible avec le partage de ressources inter-origines (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();
}