Ce document explique comment implémenter l'autorisation d'accès OAuth 2.0 les API Google à partir d'une application Web JavaScript. OAuth 2.0 permet aux utilisateurs partager des données spécifiques avec une application tout en conservant leurs noms d'utilisateur, mots de passe la confidentialité des informations. Par exemple, une application peut utiliser OAuth 2.0 pour obtenir l'autorisation aux utilisateurs de stocker des fichiers dans leurs Google Drive.
Ce flux OAuth 2.0 est appelé flux d'attribution implicite. Il est conçu pour aux applications qui accèdent aux API uniquement lorsque l'utilisateur est présent sur l'application. Ces applications ne peuvent pas stocker d'informations confidentielles.
Dans ce flux, votre application ouvre une URL Google qui utilise des paramètres de requête pour l'identifier et le type d'accès aux API requis par l'application. Vous pouvez ouvrir l'URL dans le navigateur actuel 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 pour effectuer des appels autorisés à Google, vous devez utiliser bibliothèque JavaScript Google Identity Services pour gérer le flux OAuth 2.0. Veuillez consulter Google Identity Services" modèle de jeton, qui est basé sur le flux d'attribution implicite OAuth 2.0.
Prérequis
Activer les API pour votre projet.
Toute application qui appelle des API Google doit activer ces API dans le API Console
Pour activer une API pour votre projet:
- Open the API Library dans la Google API Console
- If prompted, select a project, or create a new one.
- API Library liste toutes les API disponibles, regroupées par produit. la famille et leur popularité. Si l'API que vous souhaitez activer n'apparaît pas dans la liste, utilisez la recherche pour recherchez-le ou cliquez sur Tout afficher dans la famille de produits à laquelle il appartient.
- Sélectionnez l'API que vous souhaitez activer, puis cliquez sur le bouton Activer.
- If prompted, enable billing.
- If prompted, read and accept the API's Terms of Service.
Créer des identifiants d'autorisation
Toute application qui utilise OAuth 2.0 pour accéder aux API Google doit disposer d'identifiants d'autorisation. qui identifient l'application auprès du serveur OAuth 2.0 de Google. Les étapes suivantes expliquent comment créer des identifiants pour votre projet. Vos applications peuvent ensuite utiliser les identifiants pour accéder aux API que vous avez activées pour ce projet.
- Go to the Credentials page.
- Cliquez sur Créer des identifiants > ID client OAuth.
- Sélectionnez le type d'application Application Web.
- Remplissez le formulaire. Applications qui utilisent JavaScript pour effectuer des requêtes API Google autorisées doit spécifier des origines JavaScript autorisées. Les origines identifient les domaines permettant à votre application d'envoyer des requêtes au serveur OAuth 2.0. Ces origines doivent respecter aux règles de validation de Google.
Identifier les niveaux d'accès
Les niveaux d'accès permettent à votre application de ne demander l'accès qu'aux ressources dont elle a besoin, tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils accordent à votre application. Il existe donc peut représenter une relation inverse entre le nombre de champs d'application demandés et la probabilité l'obtention du consentement de l'utilisateur.
Avant de commencer à implémenter l'autorisation OAuth 2.0, nous vous recommandons d'identifier les champs d'application auxquelles votre application a besoin d'une autorisation d'accès.
Le document Champs d'application de l'API OAuth 2.0 contient une liste complète des champs d'application que vous pouvez utiliser pour accéder aux API Google.
Obtenir des jetons d'accès OAuth 2.0
Les étapes suivantes montrent comment votre application interagit avec le serveur OAuth 2.0 de Google pour obtenir 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: Redirection vers le serveur OAuth 2.0 de Google
Pour demander l'autorisation d'accéder aux données d'un utilisateur, redirigez ce dernier vers le protocole OAuth 2.0 Google Cloud.
Points de terminaison OAuth 2.0
Générez une URL pour demander l'accès à partir du 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 le Web applications de serveur:
| 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 où le serveur d'API redirige l'utilisateur une fois que celui-ci a effectué la
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
API Console
Credentials pageSi cette valeur ne correspond pas à
URI de redirection autorisé pour l'élément Notez que le schéma |
||||||
response_type |
Obligatoire
Les applications JavaScript doivent définir la valeur du paramètre sur |
||||||
scope |
Obligatoire
A délimité par des espaces des champs d'application qui identifient les ressources auxquelles votre application pourrait accéder au nom de l'utilisateur. Ces valeurs déterminent l'écran de consentement que Google présente aux utilisateurs utilisateur. Les niveaux d'accès permettent à votre application de ne demander l'accès qu'aux ressources dont elle a besoin tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils accordent application. Ainsi, il existe une relation inverse entre le nombre de champs d'application demandés et la probabilité d'obtenir le consentement de l'utilisateur. Nous recommandons que votre application demande l'accès aux champs d'application des autorisations en contexte dès que possible. En demandant l'accès aux données utilisateur en contexte, via l'autorisation incrémentielle, vous aidez les utilisateurs à comprendre 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 maintenir l'état entre vos
la requête d'autorisation et la réponse du serveur d'autorisation.
Le serveur renvoie la valeur exacte que vous envoyez en tant que paire Vous pouvez utiliser ce paramètre à différentes fins, par exemple pour rediriger l'utilisateur vers le
la ressource appropriée dans votre application, en envoyant des nonces et en limitant les requêtes intersites
falsification. Étant donné que votre |
||||||
include_granted_scopes |
Optional
Permet aux applications d'utiliser une autorisation incrémentielle pour demander l'accès à des
les niveaux d'accès en contexte. Si vous définissez la valeur de ce paramètre sur |
||||||
enable_granular_consent |
Optional
La valeur par défaut est Lorsque Google active des autorisations précises pour une application, ce paramètre n'ont plus d'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 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 |
||||||
prompt |
Optional
Liste de requêtes sensibles à la casse et séparées par des espaces à présenter à l'utilisateur. Si vous ne spécifiez ce paramètre, l'utilisateur n'est invité à le faire que la première fois que votre projet demande l'accès. Voir <ph type="x-smartling-placeholder"></ph> Demander un nouveau consentement pour en savoir plus. 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 faciliter la lecture.
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 dans JavaScript sans utiliser la bibliothèque cliente des API Google pour JavaScript. Puisque ce protocole OAuth 2.0 n'est pas compatible avec le partage des ressources entre origines multiples (CORS), l'extrait crée un 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 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_client
L'origine à partir de laquelle la requête a été effectuée n'est pas autorisée pour ce client. Voir
origin_mismatch
invalid_grant
Lorsque vous utilisez l'autorisation incrémentielle, le jeton a peut-être 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.
origin_mismatch
Le schéma, le domaine et/ou le port du code JavaScript à l'origine de la demande d'autorisation ne doivent pas correspondre à un URI d'origine JavaScript autorisé enregistré pour l'ID client OAuth. Examen autorisé Origines JavaScript dans le Google API Console Credentials page
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
Le schéma, le domaine et/ou le port du code JavaScript à l'origine de la demande d'autorisation ne doivent pas correspondre à un URI d'origine JavaScript autorisé enregistré pour l'ID client OAuth. Examiner les origines JavaScript autorisées Google API Console Credentials page
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
Étape 3: Gérer la réponse du serveur OAuth 2.0
Points de terminaison OAuth 2.0
Le serveur OAuth 2.0 envoie une réponse à l'adresse redirect_uri spécifiée dans votre
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 demande, la réponse contient un message d'erreur. Le jeton d'accès ou est renvoyé sur le fragment de hachage de l'URI de redirection, comme indiqué ci-dessous:
Réponse de 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 le paramètretoken_type, qui est toujours défini surBeareret le paramètreexpires_in, qui spécifie le paramètre 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 d'exemple suivante, qui demande 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
Une fois le flux OAuth 2.0 terminé, vous serez redirigé vers
http://localhost/oauth2callback Cette URL renverra un
404 NOT FOUND, sauf si votre ordinateur local diffuse un fichier sur
cette adresse. L'étape suivante fournit plus de détails sur les informations renvoyées dans le
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 effectuer des appels vers
pour le compte d'un service
compte utilisateur si les niveaux d'accès requis par l'API ont été accordés. Pour ce faire, incluez
le jeton d'accès dans une requête adressée à l'API en incluant une requête access_token
ou une valeur Bearer d'en-tête HTTP Authorization. Si possible,
l'en-tête HTTP est préférable, car les chaînes de requête ont tendance à être visibles dans les journaux du serveur. Dans la plupart des cas
vous pouvez utiliser une bibliothèque cliente pour configurer vos appels aux API Google (par exemple, lorsque
appelez l'API Drive Files).
Vous pouvez essayer toutes les API Google et consulter leurs champs d'application à la OAuth 2.0 Playground.
Exemples de requête HTTP GET
Un appel à la fonction
drive.files
(API Drive Files) via le protocole HTTP Authorization: Bearer
peut se présenter comme suit. Notez que vous devez spécifier votre propre jeton d'accès:
GET /drive/v2/files HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
Voici un appel à la même API pour l'utilisateur authentifié à l'aide de access_token.
paramètre de chaîne de requête:
GET https://www.googleapis.com/drive/v2/files?access_token=access_token
curl exemples
Vous pouvez tester ces commandes avec l'application de ligne de commande curl. Voici un
exemple qui utilise l'option d'en-tête HTTP (recommandé):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files
Vous pouvez également utiliser l'option de paramètre de chaîne de requête:
curl https://www.googleapis.com/drive/v2/files?access_token=access_token
Exemple de code JavaScript
L'extrait de code ci-dessous montre comment utiliser CORS (Cross-Origin Resource Sharing) pour envoyer un à 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 d'assistance CORS dans la documentation de cette bibliothèque vous aidera probablement pour mieux comprendre ces demandes.
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'option complète
exemple montre comment stocker ce jeton dans l'espace de stockage local du navigateur et le récupérer.
lorsque vous envoyez 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 terminer le flux OAuth 2.0 en JavaScript sans utiliser la méthode Bibliothèque cliente des API Google pour JavaScript. Le code est destiné à une page HTML qui affiche un bouton permettant essayez une requête API. Si vous cliquez sur ce bouton, le code vérifie si la page a enregistré 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, il lance le flux OAuth 2.0.
Pour le flux OAuth 2.0, la page suit les étapes suivantes:
- Elle redirige l'utilisateur vers le serveur OAuth 2.0 de Google, qui demande l'accès au
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 envoyer l'exemple de requête API.
La requête API appelle la méthode
about.getde l'API Drive pour récupérer les informations relatives au 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 le journal de débogage du navigateur. console.
Vous pouvez révoquer l'accès à l'application via la la page Autorisations de votre Compte Google. L'application sera répertoriée en tant que Démo OAuth 2.0 pour la documentation sur les API Google.
Pour exécuter ce code localement, vous devez définir des valeurs pour YOUR_CLIENT_ID et
les variables YOUR_REDIRECT_URI correspondant à vos
identifiants d'autorisation. La variable YOUR_REDIRECT_URI
doit être définie sur l'URL où la page est diffusée. La valeur doit correspondre exactement à l'une des
les URI de redirection autorisés pour le client OAuth 2.0, que vous avez configurés dans la
API Console Credentials pageSi
ne correspond pas à un URI autorisé, vous obtiendrez un redirect_uri_mismatch
. Votre projet doit également comporter
activé 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';
// 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']) {
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() {
// 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/drive.metadata.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 de l'origine JavaScript
Google applique les règles de validation suivantes aux origines JavaScript afin de les développeurs assurent la sécurité de leurs applications. Vos origines JavaScript doivent respecter ces règles. Consultez la section 3 du document RFC 3986 pour connaître les du domaine, de l'hôte et du schéma, mentionnée ci-dessous.
| Règles de validation | |
|---|---|
| Schéma |
Les origines JavaScript doivent utiliser le schéma HTTPS et non le protocole HTTP simple. URI Localhost (y compris les URI d'adresses IP de l'hôte local) 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 le domaine appartient à l'application. |
| Informations sur l'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 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 aux ressources, qui sont identifiés par des portées. Il est recommandé de demander une autorisation pour accéder aux ressources au moment où vous en avez besoin. Pour cela, le serveur d'autorisation de Google est compatible avec les autorisations incrémentielles. Cette fonctionnalité vous permet de demander des niveaux d'accès selon vos besoins. 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 niveaux d'accès accordés par l'utilisateur au projet.
Par exemple, une application permettant aux utilisateurs de sampler des titres et de créer des mix n'aura peut-être besoin que de très peu de au moment de la connexion, peut-être rien de plus que le nom de la personne qui se connecte. Toutefois, l'enregistrement d'un mix complet nécessiterait d'avoir accès à leur Google Drive. La plupart des gens le trouveraient naturel s'ils ne sont invités à accéder à leur Google Drive que lorsque l'application en avaient besoin.
Dans ce cas, au moment de la connexion, l'application peut demander le openid, puis
les champs d'application profile pour effectuer une connexion de base, puis demanderont
https://www.googleapis.com/auth/drive.file au moment de la première requête d'enregistrement d'une
d'un ensemble de données complet.
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 à n'importe quel champ d'application déployé dans le nouvelle autorisation combinée.
- Lorsque vous utilisez le jeton d'actualisation pour l'autorisation combinée afin d'obtenir un jeton d'accès,
le jeton d'accès représente l'autorisation combinée et peut être utilisé pour n'importe quelle
Valeurs
scopeincluses dans la réponse. - L'autorisation combinée inclut tous les champs d'application que l'utilisateur a accordés au projet d'API, si les subventions ont été demandées auprès de 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 au 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 à toutes ces les champs d'application des autorisations pour le compte de l'utilisateur associé sont révoqués simultanément.
Les exemples de code ci-dessous montrent comment ajouter des champs d'application à un jeton d'accès existant. Cette approche permet pour éviter d'avoir à 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 include_granted_scopes
dans votre demande au serveur OAuth 2.0 de Google.
L'extrait de code suivant montre comment procéder. Cet extrait suppose que vous avez stocké
les champs d'application pour lesquels votre jeton d'accès est valide dans le stockage local du navigateur. (Le
exemple de code complete example stocke une liste des champs d'application pour lesquels le jeton d'accès
est valide si vous définissez la propriété oauth2-test-params.scope dans le fichier
storage.)
L'extrait compare les champs d'application pour lesquels le jeton d'accès est valide à celui 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 dans
étape 2 (fournie plus loin dans la étape
exemple).
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, 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.
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 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.
L'extrait de code JavaScript suivant montre comment révoquer un jeton en JavaScript sans utiliser le
Bibliothèque cliente des API Google pour JavaScript. Étant donné que le point de terminaison OAuth 2.0 de Google
n'est pas compatible avec CORS (Cross-Origin Resource Sharing), le code crée un formulaire
le formulaire sur le point de terminaison plutôt que d'utiliser la méthode XMLHttpRequest() pour publier le
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
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.