OAuth 2.0 pour les applications Web côté client

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:

  1. Open the API Library dans la Google API Console
  2. If prompted, select a project, or create a new one.
  3. 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.
  4. Sélectionnez l'API que vous souhaitez activer, puis cliquez sur le bouton Activer.
  5. If prompted, enable billing.
  6. 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.

  1. Go to the Credentials page.
  2. Cliquez sur Créer des identifiants > ID client OAuth.
  3. Sélectionnez le type d'application Application Web.
  4. 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 client_id fourni, vous obtiendrez une Erreur redirect_uri_mismatch.

Notez que le schéma http ou https, la casse et la barre oblique finale ("/") doivent tous correspondre.

response_type Obligatoire

Les applications JavaScript doivent définir la valeur du paramètre sur token. Ce indique au serveur d'autorisation Google de renvoyer le jeton d'accès Paire name=value dans l'identifiant de fragment de l'URI (#) auquel l'utilisateur est redirigé une fois le processus d'autorisation terminé.

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 name=value dans le paramètre Identifiant de fragment d'URL (#) des redirect_uri après que l'utilisateur a donné son accord ou refusé demande d'accès.

Vous pouvez utiliser ce paramètre à différentes fins, par exemple pour rediriger l'utilisateur vers le la ressource appropriée dans votre application, en envoyant des nonces et en limitant les requêtes intersites falsification. Étant donné que votre redirect_uri peut être deviné, l'utilisation d'un state peut vous assurer qu'une connexion entrante est le résultat d'une d'authentification unique. Si vous générez une chaîne aléatoire ou encodez le hachage d'un cookie ou une autre valeur qui capture l'état du client, vous pouvez valider la réponse Assurez-vous également que la requête et la réponse proviennent du même navigateur, en offrant une protection contre les attaques demande intersites falsification. Consultez le OpenID Connect pour obtenir un exemple de création et de confirmation d'un jeton state.

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 true et que demande d'autorisation donnée, le nouveau jeton d'accès couvrira également les champs d'application auquel l'utilisateur a précédemment accordé l'accès à l'application. Consultez le autorisation incrémentielle pour obtenir des exemples.

login_hint Optional

Si votre application sait quel utilisateur tente de s'authentifier, elle peut utiliser ce paramètre pour fournir un indice au serveur d'authentification Google. Le serveur utilise l'indice pour simplifier le processus de connexion soit en préremplissant le champ de l'adresse e-mail dans le formulaire de connexion, soit en en sélectionnant la session multiconnexion appropriée.

Définissez la valeur du paramètre sur une adresse e-mail ou un identifiant sub, soit correspondant à l'ID Google de l'utilisateur.

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 :

none N'affichez pas d'écran d'authentification ou de consentement. Ne doit pas être spécifié avec d'autres valeurs.
consent Demander le consentement de l'utilisateur.
select_account Invitez l'utilisateur à sélectionner un compte.

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ètre token_type, qui est toujours défini sur Bearer et le paramètre expires_in, qui spécifie le paramètre durée de vie du jeton, en secondes. Si le paramètre state a é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:

  1. 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.
  2. 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.
  3. 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.get de l'API Drive pour récupérer les informations relatives au compte Google Drive de l'utilisateur autorisé.

  4. 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
  • Domaines de premier niveau d'hôte (Domaines de premier niveau) doit faire partie de la liste des suffixes publics.
  • Les domaines de l'hôte ne peuvent pas être “googleusercontent.com”.
  • Les origines JavaScript ne peuvent pas contenir de domaines de raccourcissement d'URL (ex. : 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:
    • Caractères génériques ('*')
    • Caractères ASCII non imprimables
    • Encodages de pourcentage incorrects (encodage de pourcentage non conforme à l'encodage d'URL) forme d'un signe de pourcentage suivi de deux chiffres hexadécimaux)
    • Caractères nuls (caractère NULL encodé, par exemple %00, %C0%80).

    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 scope incluses 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.