Authentification Cloud Storage

La plupart des opérations que vous effectuez dans Cloud Storage doivent être authentifiées. Les seules exceptions concernent les opérations réalisées sur des objets qui autorisent les accès anonymes. Les objets sont accessibles de manière anonyme si le groupe allUsers dispose de l'autorisation READ. Le groupe allUsers comprend tous les internautes.

OAuth 2.0

Authentification

Cloud Storage utilise le protocole OAuth 2.0 pour l'authentification et l'autorisation de l'API. L'authentification est le processus permettant de déterminer l'identité d'un client. Les détails de l'authentification varient selon la manière dont vous accédez à Cloud Storage, mais se divisent en deux types généraux :

  • Un flux centré sur le serveur permet à une application de détenir directement les identifiants d'un compte de service pour effectuer l'authentification. Utilisez ce flux si votre application utilise ses propres données plutôt que des données utilisateur. Vous pouvez utiliser les comptes de service par défaut des projets Google Cloud ou vous pouvez en créer d'autres.

  • Un flux centré sur l'utilisateur permet à une application d'obtenir les identifiants d'un utilisateur final. L'utilisateur se connecte pour procéder à l'authentification. Utilisez ce flux si votre application doit accéder aux données utilisateur. Pour connaître les scénarios dans lesquels un flux centré sur l'utilisateur est approprié, consultez la section Identifiants de compte utilisateur plus loin sur cette page.

N'oubliez pas que vous pouvez combiner les deux types d'authentification dans une application. Pour plus d'informations générales sur l'authentification, consultez le guide d'authentification Google Cloud.

Champs d'application

L'autorisation est le processus permettant de déterminer les autorisations dont dispose une identité authentifiée sur un ensemble de ressources spécifiées. OAuth 2.0 détermine si une identité authentifiée est autorisée à l'aide de champs d'application. Les applications utilisent des identifiants (obtenus à partir d'un flux d'authentification centré sur l'utilisateur ou sur le serveur) avec un ou plusieurs champs d'application pour demander un jeton d'accès à un serveur d'autorisation Google afin d'accéder aux ressources protégées. Par exemple, l'application A dotée d'un jeton d'accès ayant le champ d'application read-only ne peut que lire des données, tandis que l'application B dotée d'un jeton d'accès ayant le champ d'application read-write peut lire et modifier des données. Aucune des deux applications ne peut lire ni modifier les listes de contrôle d'accès sur les objets et les buckets. Seule une application ayant le champ d'application full-control peut le faire.

Type Description URL du champ d'application
read-only Octroie un accès ne permettant que de lire les données, y compris de répertorier les buckets. https://www.googleapis.com/auth/devstorage.read_only
read-write Octroie un accès permettant de lire et de modifier les données, mais pas les métadonnées telles que les stratégies IAM. https://www.googleapis.com/auth/devstorage.read_write
full-control Permet d'exercer un contrôle total sur les données, y compris de modifier les stratégies IAM. https://www.googleapis.com/auth/devstorage.full_control
cloud-platform.read-only Permet d'afficher les données dans les services Google Cloud. Pour Cloud Storage, ce champ d'application est identique à devstorage.read-only. https://www.googleapis.com/auth/cloud-platform.read-only
cloud-platform Permet d'afficher et de gérer les données dans tous les services Google Cloud. Pour Cloud Storage, ce champ d'application est identique à devstorage.full-control. https://www.googleapis.com/auth/cloud-platform

Authentification gsutil

Lorsque gsutil est installé à partir du SDK Cloud, vous devez vous authentifier avec des identifiants de compte de service.

  1. Utilisez un compte de service existant ou créez-en un, puis téléchargez la clé privée associée. Vous ne pouvez télécharger les données de clé privée d'une clé de compte de service qu'au moment où vous la créez.

  2. Exécutez gcloud auth activate-service-account pour vous authentifier à l'aide du compte de service :

    gcloud auth activate-service-account --key-file KEY_FILE

    Où KEY_FILE est le nom du fichier contenant les identifiants de votre compte de service.

gcloud auth utilise le champ d'application cloud-platform lors de l'obtention d'un jeton d'accès.

Si vous avez installé gsutil indépendamment du SDK Cloud, consultez la page d'installation de gsutil pour obtenir des informations sur la procédure d'authentification.

Authentification des bibliothèques clientes

Les bibliothèques clientes peuvent utiliser les identifiants par défaut de l'application pour s'authentifier facilement auprès des API Google et envoyer des requêtes à ces API. Ces identifiants vous permettent de tester votre application localement et de la déployer sans modifier le code sous-jacent. Pour obtenir davantage d'informations, y compris des exemples de code, consultez le Guide d'authentification Google Cloud Platform.

Authentification de l'API

Pour envoyer des requêtes à l'aide d'OAuth 2.0 à l'API XML ou l'API JSON Cloud Storage, incluez le jeton d'accès de votre application dans l'en-tête Authorization de chaque requête qui nécessite une authentification. Vous pouvez générer un jeton d'accès depuis la page OAuth 2.0 Playground.

Authorization: Bearer OAUTH2_TOKEN

Vous trouverez ci-dessous un exemple de requête qui répertorie les objets d'un bucket.

API JSON

Utilisez la méthode list de la ressource Objects.

GET /storage/v1/b/example-bucket/o HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

Pour autoriser des requêtes à partir de la ligne de commande ou pour les tester, vous pouvez exécuter la commande curl avec la syntaxe suivante :

curl -H "Authorization: Bearer OAUTH2_TOKEN" "https://storage.googleapis.com/storage/v1/b/BUCKET_NAME/o"

Pour les tests en local, vous pouvez exécuter la commande gcloud auth application-default print-access-token pour générer un jeton.

API XML

Utilisez une requête Répertorier les objets.

GET / HTTP/1.1
Host: example-bucket.storage.googleapis.com
Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg

Pour autoriser des requêtes à partir de la ligne de commande ou pour les tester, vous pouvez exécuter la commande curl avec la syntaxe suivante :

curl -H "Authorization: Bearer OAUTH2_TOKEN" "https://BUCKET_NAME.storage.googleapis.com"

Pour les tests en local, vous pouvez exécuter la commande gcloud auth application-default print-access-token pour générer un jeton.

En raison de la complexité de la gestion et de l'actualisation des jetons d'accès, et du risque de sécurité lié à l'interaction directe avec des applications de chiffrement, nous vous encourageons vivement à utiliser une bibliothèque cliente validée.

Si vous recherchez des clés HMAC à utiliser avec l'API XML pour obtenir un accès en interopérabilité avec Amazon S3, consultez la page Gérer des clés HMAC pour les comptes de service.

Identifiants de compte utilisateur

Utilisez les identifiants de compte utilisateur pour l'authentification lorsque votre application doit accéder aux données au nom d'un utilisateur. Sinon, utilisez des identifiants de compte de service. Voici des exemples de scénarios dans lesquels les identifiants de compte utilisateur peuvent être employés :

  • Applications de serveur Web
  • Applications de bureau et applications installées
  • Applications mobiles
  • Code JavaScript côté client
  • Applications sur des périphériques à saisie limitée

Pour plus d'informations sur ces scénarios, consultez la section Scénarios OAuth 2.0.

Si vous concevez une application de sorte qu'elle accepte plusieurs options d'authentification pour les utilisateurs finaux, utilisez l'authentification Firebase, qui accepte l'authentification par e-mail et par mot de passe, ainsi que la connexion fédérée via des fournisseurs d'identité tels que Google, Facebook, Twitter et GitHub.

Lorsqu'une application se voit attribuer un jeton d'accès dans un flux d'authentification centré sur l'utilisateur par un utilisateur final, ce jeton d'accès ne dispose que des autorisations disponibles pour l'utilisateur qui octroie le jeton. Par exemple, si jane@gmail.com dispose d'un accès read-only à example-bucket, une application à laquelle Jane a accordé un accès read-write ne peut pas écrire dans example-bucket en son nom.

Étape suivante