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 Platform 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 en savoir plus sur l'authentification, consultez le guide d'authentification Google Cloud Platform.

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 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 Platform. 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 Platform. 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.

  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

Client libraries can use Application Default Credentials to easily authenticate with Google APIs and send requests to those APIs. With Application Default Credentials, you can test your application locally and deploy it without changing the underlying code. For more information, including code samples, see Google Cloud Platform Auth Guide.

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.

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

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

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 de développeur à utiliser avec l'API XML pour obtenir un accès en interopérabilité avec Amazon S3, consultez la section Gérer des clés de développeur pour une migration simple.

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 les 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.

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.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Besoin d'aide ? Consultez notre page d'assistance.