Autenticación de Cloud Storage

La mayoría de las operaciones que realizas en Cloud Storage se deben autenticar. Las únicas excepciones son las operaciones en recursos que permiten el acceso anónimo. Un recurso tiene acceso anónimo si el grupo allUsers está incluido en la LCA del recurso o si el grupo allUsers está incluido en una política de IAM que se aplica al recurso. El grupo allUsers incluye a cualquier persona en Internet.

OAuth 2.0

Autenticación

Cloud Storage usa OAuth 2.0 para la autenticación y autorización de API. La autenticación es el proceso que determina la identidad de un cliente. Los detalles de la autenticación varían según la forma en que accedas a Cloud Storage, pero se dividen en dos tipos generales:

  • Un flujo centrado en el servidor permite que una aplicación contenga las credenciales de una cuenta de servicio de forma directa para completar la autenticación. Usa este flujo si tu aplicación trabaja con sus propios datos en lugar de los datos del usuario. Los proyectos de Google Cloud tienen cuentas de servicio predeterminadas que puedes usar, o bien puedes crear cuentas nuevas.

  • Un flujo centrado en el usuario permite que una aplicación obtenga credenciales de un usuario final. El usuario debe acceder para completar la autenticación. Usa este flujo si tu aplicación necesita acceder a los datos del usuario. Consulta la sección Credenciales de la cuenta de usuario más adelante en esta página para conocer las situaciones en las que es adecuado usar un flujo centrado en el usuario.

Ten en cuenta que puedes usar ambos tipos de autenticación juntos en una aplicación. Para obtener más información general sobre la autenticación, consulta la guía de autenticación de Google Cloud.

Alcances

La autorización es el proceso que determina qué permisos tiene una identidad autenticada en un conjunto de recursos especificados. OAuth 2.0 usa alcances para determinar si una identidad autenticada está autorizada. Las aplicaciones usan una credencial (obtenida de un flujo de autenticación centrado en el usuario o en el servidor) junto con uno o más alcances para solicitar un token de acceso de un servidor de autorización de Google a fin de acceder a los recursos protegidos. Por ejemplo, la aplicación A con un token de acceso con el alcance read-only solo puede realizar operaciones de lectura, mientras que la aplicación B con un token de acceso con el alcance read-write puede leer y modificar datos. Ninguna de las dos puede leer o modificar las listas de control de acceso en los objetos y depósitos; solo una aplicación con el alcance full-control puede hacerlo.

Tipo Descripción URL del alcance
read-only Solo permite el acceso de lectura a los datos, lo que incluye la enumeración de depósitos. https://www.googleapis.com/auth/devstorage.read_only
read-write Permite el acceso para leer y cambiar datos, pero no metadatos como las políticas de IAM. https://www.googleapis.com/auth/devstorage.read_write
full-control Permite el control total sobre los datos, incluida la capacidad de modificar las políticas de IAM. https://www.googleapis.com/auth/devstorage.full_control
cloud-platform.read-only Permite ver tus datos en los servicios de Google Cloud. En Cloud Storage, esto es lo mismo que devstorage.read-only. https://www.googleapis.com/auth/cloud-platform.read-only
cloud-platform Permite ver y administrar datos en todos los servicios de Google Cloud. En Cloud Storage, esto es lo mismo que devstorage.full-control. https://www.googleapis.com/auth/cloud-platform

Autenticación de la interfaz de línea de comandos

Si trabajas con Cloud Storage mediante Google Cloud CLI, por lo general, debes autenticarte con las credenciales de tu cuenta de usuario. Para hacerlo, ejecuta el comando gcloud auth login y sigue las instrucciones, que incluyen el acceso a tu cuenta de usuario. Si deseas ver opciones de autenticación adicionales, consulta Autentica para usar gcloud CLI.

Autenticación de bibliotecas cliente

Las bibliotecas cliente pueden usar las credenciales predeterminadas de la aplicación para autenticarse fácilmente con las APIs de Google y enviar solicitudes a esas API. Con las credenciales predeterminadas de la aplicación, puedes probar tu aplicación de forma local y, luego, implementarla sin cambiar el código subyacente. Para obtener más información, consulta <atrack-type="commonincludes" l10n-attrs-original-order="href,track-type,track-name" l10n-encrypted-href="WDE63JFVMK0YqIWBqG8nCycgwkRfOeEqRvzYs1N+2tJUEhcZvE5VtDH5LoWw0lj/" track-name="referenceLink"> Se autentica para usar las bibliotecas cliente.</atrack-type="commonincludes">

  • Google Cloud

    Si ejecutas tu aplicación en servicios que admiten cuentas de servicio conectadas, como App Engine, Cloud Functions, Cloud Run o Compute Engine, el entorno ya proporciona la información de autenticación de la cuenta de servicio, por lo que no se requiere más configuración. Para Compute Engine, el alcance de la cuenta de servicio depende de cómo se crea la instancia. Consulta Permisos de acceso en la documentación de Compute Engine. En App Engine, se usa el alcance cloud-platform.

  • Otros entornos

    Para inicializar tu entorno local de producción o desarrollo, crea una cuenta de servicio de Google Cloud, descarga su clave y configura la variable de entorno GOOGLE_APPLICATION_CREDENTIALS a fin de usar la clave. Para obtener información paso a paso, consulta la sección sobre cómo configurar la autenticación con las bibliotecas cliente de Cloud Storage.

Autenticación de API

Para realizar solicitudes a la API de XML o la API de JSON de Cloud Storage mediante OAuth 2.0, incluye el token de acceso de tu aplicación en el encabezado Authorization en todas las solicitudes que requieran autenticación. Puedes generar un token de acceso desde OAuth 2.0 Playground.

  1. En OAuth 2.0 Playground, haz clic en laversión 1 de la API de Cloud Storage y, luego, selecciona un nivel de acceso para la aplicación (full_control, read_only o read_write).

  2. Haz clic en Autorizar API.

  3. Accede a tu cuenta cuando se te solicite. En el cuadro de diálogo que aparece, haz clic en Permitir.

  4. En el paso 2 de la zona de pruebas, haz clic en Código de autorización de intercambio para tokens del código de autorización que aparece.

  5. Copia tu token de acceso y, luego, inclúyelo en el encabezado Authorization de tu solicitud:

    Authorization: Bearer OAUTH2_TOKEN

El siguiente es un ejemplo de una solicitud que enumera los objetos de un bucket.

API de JSON

Usa el método list del recurso Objetos.

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

Para autorizar solicitudes desde la línea de comandos o realizar pruebas, puedes usar el comando curl con la siguiente sintaxis:

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

Para realizar pruebas locales, puedes usar el comando gcloud auth application-default print-access-token a fin de generar un token.

API de XML

Usa una solicitud de Enumerar objetos.

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

Para autorizar solicitudes desde la línea de comandos o realizar pruebas, puedes usar el comando curl con la siguiente sintaxis:

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

Para realizar pruebas locales, puedes usar el comando gcloud auth application-default print-access-token a fin de generar un token.

Debido a la complejidad de administrar y actualizar los tokens de acceso y el riesgo de seguridad cuando se trata con aplicaciones criptográficas de forma directa, recomendamos que uses una biblioteca cliente verificada.

Si buscas claves HMAC para usar con la API de XML a fin de obtener acceso interoperable con Amazon S3, consulta Administra las claves HMAC para las cuentas de servicio.

Credenciales de cuenta de usuario

Usa credenciales de cuenta de usuario para la autenticación cuando tu aplicación requiere acceso a los datos en nombre de un usuario; de lo contrario, usa credenciales de cuenta de servicio. A continuación, se muestran ejemplos de situaciones en las que se pueden usar credenciales de cuenta de usuario:

  • Aplicaciones de servidor web
  • Aplicaciones instaladas y de escritorio
  • Aplicaciones para dispositivos móviles
  • JavaScript de cliente
  • Aplicaciones en dispositivos de entrada limitada

Para obtener más información sobre estas situaciones, consulta la página sobre situaciones de OAuth 2.0.

Si diseñas una aplicación de forma que admita múltiples opciones de autenticación para usuarios finales, usa Firebase Authentication, que admite la autenticación con correo electrónico y contraseña, así como el acceso federado con proveedores de identidad como Google, Facebook, Twitter y GitHub. Consulta ¿Por dónde empiezo con Firebase Authentication? a fin de obtener detalles sobre cómo configurar los sistemas de autenticación para diferentes casos de uso.

Cuando un usuario final otorga un token de acceso a una aplicación en un flujo de autenticación centrado en el usuario, ese token de acceso solo tendrá los permisos disponibles para el usuario que lo otorga. Por ejemplo, si jane@gmail.com tiene el acceso read-only a example-bucket, una aplicación a la que Jane otorgó el acceso read-write no podrá escribir para example-bucket en su nombre.

¿Qué sigue?