Uso de OAuth 2.0 para aplicaciones de servidor a servidor

El sistema Google OAuth 2.0 admite interacciones de servidor a servidor, como las que existen entre una aplicación web y un servicio de Google. Para este escenario necesita una cuenta de servicio, que es una cuenta que pertenece a su aplicación en lugar de a un usuario final individual. Su aplicación llama a las API de Google en nombre de la cuenta de servicio, por lo que los usuarios no se involucran directamente. Este escenario a veces se denomina "OAuth de dos patas" o "2LO". (El término relacionado "OAuth de tres patas" se refiere a situaciones en las que su aplicación llama a las API de Google en nombre de los usuarios finales y en las que a veces se requiere el consentimiento del usuario).

Normalmente, una aplicación utiliza una cuenta de servicio cuando la aplicación utiliza las API de Google para trabajar con sus propios datos en lugar de los datos de un usuario. Por ejemplo, una aplicación que usa Google Cloud Datastore para la persistencia de datos usaría una cuenta de servicio para autenticar sus llamadas a la API de Google Cloud Datastore.

Los administradores de dominio Google espacio de trabajo también puede conceder autoridad cuentas de servicio de todo el dominio a los datos de acceso de usuario en nombre de los usuarios en el dominio.

Este documento describe cómo una aplicación puede completar el flujo de OAuth 2.0 de servidor a servidor mediante el uso de una biblioteca cliente de las API de Google (recomendado) o HTTP.

Visión general

Para apoyar las interacciones de servidor a servidor, primero debe crear una cuenta de servicio para su proyecto en el API Console. Si desea acceder a los datos de los usuarios de su cuenta de Google Workspace, delegue el acceso de todo el dominio a la cuenta de servicio.

Luego, su aplicación se prepara para realizar llamadas API autorizadas mediante el uso de las credenciales de la cuenta de servicio para solicitar un token de acceso del servidor de autenticación OAuth 2.0.

Finalmente, su aplicación puede usar el token de acceso para llamar a las API de Google.

Crear una cuenta de servicio

Las credenciales de una cuenta de servicio incluyen una dirección de correo electrónico generada que es única y al menos un par de claves pública / privada. Si la delegación de todo el dominio está habilitada, una ID de cliente también forma parte de las credenciales de la cuenta de servicio.

Si su aplicación se ejecuta en Google App Engine, una cuenta de servicio se configura automáticamente cuando crea su proyecto.

Si tu aplicación se ejecuta en Google Compute Engine, también se configura una cuenta de servicio automáticamente cuando creas tu proyecto, pero debes especificar los alcances a los que tu aplicación necesita acceder cuando creas una instancia de Google Compute Engine. Para obtener más información, consulte Preparación de una instancia de cuentas de servicio de uso .

Si su aplicación no se ejecuta en Google App Engine o Google Compute Engine, debe obtener estas credenciales en el Google API Console. Para generar credenciales de cuenta de servicio o para ver las credenciales públicas que ya ha generado, haga lo siguiente:

  1. 打开Service accounts page
  2. If prompted, select a project, or create a new one.
  3. 单击 创建服务帐户
  4. 在“ 服务帐户详细信息”下 ,键入服务帐户的名称,ID和描述,然后单击“ 创建”
  5. 可选:在“ 服务帐户权限”下 ,选择要授予服务帐户的IAM角色,然后单击继续
  6. 可选:在“ 授予用户对此服务帐户的访问权限”下 ,添加允许使用和管理该服务帐户的用户或组。
  7. 单击 创建密钥 ,然后单击创建

您的新公钥/私钥对已生成并下载到您的计算机;它充当私钥的唯一副本。您有责任安全地存储它。如果丢失此密钥对,则需要生成一个新的密钥对。

如果您需要向服务帐户授予G Suite域范围内的权限 ,请单击您创建的服务帐户的电子邮件地址,然后从“ 唯一ID”框中复制该值。

要将权限委派给服务帐户,请使用复制的值作为客户端ID。

Puede volver a la API Console en cualquier momento para ver la dirección de correo electrónico, las huellas digitales de clave pública, y otra información, o para generar pares de claves privadas / públicas adicionales. Para más detalles sobre las credenciales de cuenta de servicio en el API Console, ver las cuentas de servicio en el API Consolearchivo de ayuda.

Tome nota de la dirección de correo electrónico de la cuenta de servicio y almacene el archivo de clave privada de la cuenta de servicio en una ubicación accesible para su aplicación. Su aplicación los necesita para realizar llamadas API autorizadas.

Delegar autoridad en todo el dominio a la cuenta de servicio

Si tiene una cuenta de Google Workspace, un administrador de la organización puede autorizar que una aplicación acceda a los datos del usuario en nombre de los usuarios del dominio de Google Workspace. Por ejemplo, una aplicación que usa la API de Google Calendar para agregar eventos a los calendarios de todos los usuarios en un dominio de Google Workspace usaría una cuenta de servicio para acceder a la API de Google Calendar en nombre de los usuarios. Autorizar a una cuenta de servicio para acceder a datos en nombre de los usuarios de un dominio a veces se denomina "delegación de autoridad en todo el dominio" a una cuenta de servicio.

Para delegar la autoridad de todo el dominio a una cuenta de servicio, primero habilitar la delegación de todo el dominio de una cuenta de servicio existente en el Service accounts page o crear una nueva cuenta de servicio con la delegación de todo el dominio permitido.

Luego, un superadministrador del dominio de Google Workspace debe completar los siguientes pasos:

  1. A partir de su dominio de Google espacio de trabajo Consola de administración , vaya a Menú principal > Seguridad> Controles API.
  2. En el panel delegación de todo el dominio, seleccione Administrar todo el dominio Delegación.
  3. Haga clic en Agregar nuevo.
  4. En el campo ID de cliente, introduzca la cuenta de servicio de ID de cliente. Usted puede encontrar su cuenta de servicio de identificación de cliente en el Service accounts page.
  5. En los ámbitos de OAuth campo (delimitado por comas), entrar en la lista de ámbitos que su aplicación se debe conceder acceso. Por ejemplo, si la aplicación necesita acceso al dominio de toda completo a la API de Google Drive y el API de Google Calendar, entre: https://www.googleapis.com/auth/drive, https://www.googleapis.com/auth / calendario.
  6. Haga clic en Autorizar.

Su aplicación ahora tiene la autoridad para realizar llamadas a la API como usuarios en su dominio (para "hacerse pasar por usuarios"). Cuando se prepara para realizar llamadas API autorizadas, especifica el usuario para suplantar.

Preparándose para realizar una llamada API autorizada

Java

Después de obtener la dirección de correo electrónico del cliente y la clave privada de la API Console, utilizar la biblioteca de clientes API de Google para Java para crear un GoogleCredential objeto a partir de las credenciales de la cuenta de servicio y los alcances de su aplicación necesita acceso a. Por ejemplo:

import com.google.api.client.googleapis.auth.oauth2.GoogleCredential;
import com.google.api.services.sqladmin.SQLAdminScopes;

// ...

GoogleCredential credential = GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json"))
    .createScoped(Collections.singleton(SQLAdminScopes.SQLSERVICE_ADMIN));

Si está desarrollando una aplicación en Google Cloud Platform, puede utilizar las credenciales predeterminadas aplicación en su lugar, lo que puede simplificar el proceso.

Delegar autoridad en todo el dominio

Si ha delegado el acceso de todo el dominio de la cuenta de servicio y quiere hacerse pasar por una cuenta de usuario, especifique la dirección de correo electrónico de la cuenta de usuario con la createDelegated método de la GoogleCredential objeto. Por ejemplo:

GoogleCredential credential = GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json"))
    .createScoped(Collections.singleton(SQLAdminScopes.SQLSERVICE_ADMIN))
    .createDelegated("user@example.com");

Usar la GoogleCredential objeto para llamar a las API de Google en su aplicación.

Pitón

Después de obtener la dirección de correo electrónico del cliente y la clave privada de la API Console, utilizar la biblioteca de clientes API de Google para Python para completar los siguientes pasos:

  1. Crear un Credentials objeto a partir de las credenciales de la cuenta de servicio y los alcances de su aplicación necesita acceso a. Por ejemplo:
    from google.oauth2 import service_account
    
    SCOPES = ['https://www.googleapis.com/auth/sqlservice.admin']
    SERVICE_ACCOUNT_FILE = '/path/to/service.json'
    
    credentials = service_account.Credentials.from_service_account_file(
            SERVICE_ACCOUNT_FILE, scopes=SCOPES)

    Si está desarrollando una aplicación en Google Cloud Platform, puede utilizar las credenciales predeterminadas aplicación en su lugar, lo que puede simplificar el proceso.

  2. Delegar autoridad en todo el dominio

    Si ha delegado el acceso de todo el dominio de la cuenta de servicio y quiere hacerse pasar por una cuenta de usuario, utilice el with_subject método de un existente ServiceAccountCredentials objeto. Por ejemplo:

    delegated_credentials = credentials.with_subject('user@example.org')

Utilice el objeto Credentials para llamar a las API de Google en su aplicación.

HTTP / REST

Después de obtener el ID de cliente y una clave privada de la API Console, su aplicación tiene que completar los siguientes pasos:

  1. Cree un token web JSON (JWT, pronunciado, "jot") que incluya un encabezado, un conjunto de reclamos y una firma.
  2. Solicite un token de acceso del servidor de autorización de Google OAuth 2.0.
  3. Maneja la respuesta JSON que devuelve el servidor de autorización.

Las secciones que siguen describen cómo completar estos pasos.

Si la respuesta incluye un token de acceso, se puede utilizar el token de acceso para llamar a una API de Google . (Si la respuesta no incluye un token de acceso, es posible que su JWT y su solicitud de token no estén formados correctamente o que la cuenta de servicio no tenga permiso para acceder a los ámbitos solicitados).

Cuando el testigo de acceso expira , su aplicación genera otro JWT, lo firma, y solicita otro token de acceso.

Su aplicación de servidor usa un JWT para solicitar un token del servidor de autorización de Google y luego usa el token para llamar a un punto final de la API de Google. Ningún usuario final está involucrado.

El resto de esta sección describe los detalles de la creación de un JWT, la firma del JWT, la formación de la solicitud del token de acceso y el manejo de la respuesta.

Creando un JWT

Un JWT se compone de tres partes: un encabezado, un conjunto de reclamos y una firma. El encabezado y el conjunto de notificaciones son objetos JSON. Estos objetos JSON se serializan en bytes UTF-8 y luego se codifican con la codificación Base64url. Esta codificación proporciona resistencia frente a los cambios de codificación debidos a operaciones de codificación repetidas. La cabecera, conjunto de reivindicaciones, y la firma se concatenan entre sí por un punto ( . ) Carácter.

Un JWT se compone de la siguiente manera:

{Base64url encoded header}.{Base64url encoded claim set}.{Base64url encoded signature}

La cadena base para la firma es la siguiente:

{Base64url encoded header}.{Base64url encoded claim set}
Formando el encabezado JWT

El encabezado consta de dos campos que indican el algoritmo de firma y el formato de la aserción. Ambos campos son obligatorios y cada campo tiene un solo valor. A medida que se introducen algoritmos y formatos adicionales, este encabezado cambiará en consecuencia.

Las cuentas de servicio se basan en el algoritmo RSA SHA-256 y el formato de token JWT. Como resultado, la representación JSON del encabezado es la siguiente:

{"alg":"RS256","typ":"JWT"}

La representación de Base64url de esto es la siguiente:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9
Formación del conjunto de reclamaciones de JWT

El conjunto de notificaciones de JWT contiene información sobre el JWT, incluidos los permisos que se solicitan (ámbitos), el destino del token, el emisor, la hora en que se emitió el token y la duración del token. La mayoría de los campos son obligatorios. Al igual que el encabezado JWT, el conjunto de notificaciones JWT es un objeto JSON y se utiliza en el cálculo de la firma.

Reclamaciones requeridas

Las reclamaciones requeridas en el conjunto de reclamaciones de JWT se muestran a continuación. Pueden aparecer en cualquier orden en el conjunto de notificaciones.

Nombre Descripción
iss La dirección de correo electrónico de la cuenta de servicio.
scope Una lista delimitada por espacios de los permisos que solicita la aplicación.
aud Un descriptor del objetivo previsto de la aserción. Al realizar una solicitud de token de acceso de este valor es siempre https://oauth2.googleapis.com/token .
exp La hora de vencimiento de la aserción, especificada como segundos desde las 00:00:00 UTC, 1 de enero de 1970. Este valor tiene un máximo de 1 hora después de la hora emitida.
iat La hora a la que se emitió la aserción, especificada en segundos desde las 00:00:00 UTC del 1 de enero de 1970.

La representación JSON de los campos obligatorios en un conjunto de notificaciones JWT se muestra a continuación:

{
  "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
  "scope": "https://www.googleapis.com/auth/devstorage.read_only",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1328554385,
  "iat": 1328550785
}
Reclamaciones adicionales

En algunos casos empresariales, una aplicación puede utilizar la delegación de todo el dominio para actuar en nombre de un usuario en particular en una organización. El permiso para realizar este tipo de suplantación de identidad se debe otorgar antes de que una aplicación pueda suplantar a un usuario y, por lo general, lo maneja un superadministrador. Para obtener más información, véase el acceso a la API de control con la delegación de todo el dominio .

Para obtener un token de acceso que concede una aplicación delegado el acceso a un recurso, incluir la dirección de correo electrónico del usuario en el conjunto de reivindicaciones JWT como el valor de la sub campo.

Nombre Descripción
sub La dirección de correo electrónico del usuario para el que la aplicación solicita acceso delegado.

Si una aplicación no tiene permiso para hacerse pasar por un usuario, la respuesta a una solicitud de token de acceso que incluye el sub campo será un error .

Un ejemplo de un conjunto de reivindicaciones JWT que incluye la sub A continuación se muestra el campo:

{
  "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
  "sub": "some.user@example.com",
  "scope": "https://www.googleapis.com/auth/prediction",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1328554385,
  "iat": 1328550785
}
Codificación del conjunto de notificaciones JWT

Al igual que el encabezado JWT, el conjunto de notificaciones JWT debe serializarse en UTF-8 y codificado en Base64url. A continuación, se muestra un ejemplo de una representación JSON de un conjunto de notificaciones JWT:

{
  "iss": "761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
  "scope": "https://www.googleapis.com/auth/prediction",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1328554385,
  "iat": 1328550785
}
Calcular la firma

Firma web JSON (JWS) es la especificación que guía la mecánica de la generación de la firma para el JWT. La entrada para la firma es la matriz de bytes del siguiente contenido:

{Base64url encoded header}.{Base64url encoded claim set}

El algoritmo de firma en el encabezado JWT debe usarse al calcular la firma. El único algoritmo de firma compatible con el servidor de autorización de Google OAuth 2.0 es RSA que utiliza el algoritmo hash SHA-256. Esto se expresa como RS256 en el alg campo en la cabecera JWT.

Firma el representación UTF-8 de la entrada utilizando SHA256withRSA (también conocido como RSASSA-PKCS1-v1_5-SIGN con la función hash SHA-256) con la clave privada obtenido de la Google API Console. La salida será una matriz de bytes.

Luego, la firma debe estar codificada en Base64url. La cabecera, conjunto de reivindicaciones, y la firma se concatenan entre sí por un punto ( . ) Carácter. El resultado es el JWT. Debería ser lo siguiente (saltos de línea agregados para mayor claridad):

{Base64url encoded header}.
{Base64url encoded claim set}.
{Base64url encoded signature}

A continuación se muestra un ejemplo de un JWT antes de la codificación Base64url:

{"alg":"RS256","typ":"JWT"}.
{
"iss":"761326798069-r5mljlln1rd4lrbhg75efgigp36m78j5@developer.gserviceaccount.com",
"scope":"https://www.googleapis.com/auth/prediction",
"aud":"https://oauth2.googleapis.com/token",
"exp":1328554385,
"iat":1328550785
}.
[signature bytes]

A continuación se muestra un ejemplo de un JWT que se ha firmado y está listo para su transmisión:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL29hdXRoMi92NC90b2tlbiIsImV4cCI6MTMyODU1NDM4NSwiaWF0IjoxMzI4NTUwNzg1fQ.UFUt59SUM2_AW4cRU8Y0BYVQsNTo4n7AFsNrqOpYiICDu37vVt-tw38UKzjmUKtcRsLLjrR3gFW3dNDMx_pL9DVjgVHDdYirtrCekUHOYoa1CMR66nxep5q5cBQ4y4u2kIgSvChCTc9pmLLNoIem-ruCecAJYgI9Ks7pTnW1gkOKs0x3YpiLpzplVHAkkHztaXiJdtpBcY1OXyo6jTQCa3Lk2Q3va1dPkh_d--GU2M5flgd8xNBPYw4vxyt0mP59XZlHMpztZt0soSgObf7G3GXArreF_6tpbFsS3z2t5zkEiHuWJXpzcYr5zWTRPDEHsejeBSG8EgpLDce2380ROQ

Realización de la solicitud del token de acceso

Después de generar el JWT firmado, una aplicación puede usarlo para solicitar un token de acceso. Este token de acceso es una petición HTTPS POST solicitud, y el cuerpo es el URL codificada. La URL se muestra a continuación:

https://oauth2.googleapis.com/token

Se requieren los siguientes parámetros en el HTTPS POST solicitud:

Nombre Descripción
grant_type Utilice la siguiente cadena, una URL codificada según sea necesario: urn:ietf:params:oauth:grant-type:jwt-bearer
assertion El JWT, incluida la firma.

A continuación se muestra un volcado de la prima HTTPS POST solicitud utilizado en un token de acceso solicitud:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS9vL29hdXRoMi90b2tlbiIsImV4cCI6MTMyODU3MzM4MSwiaWF0IjoxMzI4NTY5NzgxfQ.ixOUGehweEVX_UKXv5BbbwVEdcz6AYS-6uQV6fGorGKrHf3LIJnyREw9evE-gs2bmMaQI5_UbabvI4k-mQE4kBqtmSpTzxYBL1TCd7Kv5nTZoUC1CmwmWCFqT9RE6D7XSgPUh_jF1qskLa2w0rxMSjwruNKbysgRNctZPln7cqQ

A continuación se muestra la misma petición, utilizando curl :

curl -d 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS9vL29hdXRoMi90b2tlbiIsImV4cCI6MTMyODU3MzM4MSwiaWF0IjoxMzI4NTY5NzgxfQ.RZVpzWygMLuL-n3GwjW1_yhQhrqDacyvaXkuf8HcJl8EtXYjGjMaW5oiM5cgAaIorrqgYlp4DPF_GuncFqg9uDZrx7pMmCZ_yHfxhSCXru3gbXrZvAIicNQZMFxrEEn4REVuq7DjkTMyCMGCY1dpMa8aWfTQFt3Eh7smLchaZsU
' https://oauth2.googleapis.com/token

Manejando la respuesta

Si el JWT y la solicitud del token de acceso están formados correctamente y la cuenta de servicio tiene permiso para realizar la operación, la respuesta JSON del servidor de autorización incluye un token de acceso. La siguiente es una respuesta de ejemplo:

{
  "access_token": "1/8xbJqaOZXSUZbHLl5EOtu1pxz3fmmetKx9W8CV4t79M",
  "scope": "https://www.googleapis.com/auth/prediction"
  "token_type": "Bearer",
  "expires_in": 3600
}

Los tokens de acceso pueden ser reutilizados durante la ventana de tiempo especificado por el expires_in valor.

Llamar a las API de Google

Java

Usar la GoogleCredential objeto para llamar a las API de Google, completando los siguientes pasos:

  1. Crear un objeto de servicio de la API que desea llamar usando el GoogleCredential objeto. Por ejemplo:
    SQLAdmin sqladmin =
        new SQLAdmin.Builder(httpTransport, JSON_FACTORY, credential).build();
  2. Hacer peticiones al servicio API utilizando la interfaz proporcionada por el objeto de servicio . Por ejemplo, para enumerar las instancias de bases de datos SQL de la nube en el apasionante proyecto-ejemplo-123:
    SQLAdmin.Instances.List instances =
        sqladmin.instances().list("exciting-example-123").execute();

Pitón

Utilice los autorizados Credentials objeto de llamar las API de Google, completando los siguientes pasos:

  1. Cree un objeto de servicio para la API que desea llamar. Usted construye aa objeto de servicio llamando a la build función con el nombre y la versión de la API y la autorizada Credentials objeto. Por ejemplo, para llamar a la versión 1beta3 de la API de administración de la nube SQL:
    import googleapiclient.discovery
    
    sqladmin = googleapiclient.discovery.build('sqladmin', 'v1beta3', credentials=credentials)
  2. Hacer peticiones al servicio API utilizando la interfaz proporcionada por el objeto de servicio . Por ejemplo, para enumerar las instancias de bases de datos SQL de la nube en el apasionante proyecto-ejemplo-123:
    response = sqladmin.instances().list(project='exciting-example-123').execute()

HTTP / REST

Una vez que su aplicación obtiene un token de acceso, puede usar el token para realizar llamadas a una API de Google en nombre de una cuenta de servicio o cuenta de usuario determinada si se han otorgado los alcances de acceso requeridos por la API. Para ello, incluya el acceso de ficha en una solicitud a la API mediante la inclusión de un bien access_token parámetro de consulta o un Authorization cabecera HTTP Bearer valor. Cuando es posible, es preferible el encabezado HTTP, porque las cadenas de consulta tienden a ser visibles en los registros del servidor. En la mayoría de los casos se puede utilizar una biblioteca de cliente para configurar sus llamadas a las API de Google (por ejemplo, al llamar a la API de archivos de la unidad ).

Puede probar todas las API de Google y ver sus alcances en el espacio OAuth 2.0 .

Ejemplos de HTTP GET

Una llamada a la drive.files punto final (la API de archivos de la unidad) utilizando la Authorization: Bearer cabecera HTTP podría parecerse a lo siguiente. Tenga en cuenta que debe especificar su propio token de acceso:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

Aquí es una llamada a la misma API para el usuario autenticado mediante el access_token parámetro de cadena de consulta:

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curl ejemplos

Puede probar estos comandos con el curl la aplicación de línea de comandos. Aquí hay un ejemplo que usa la opción de encabezado HTTP (preferido):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

O, alternativamente, la opción de parámetro de cadena de consulta:

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

Cuando caducan los tokens de acceso

Tokens de acceso emitido por el Google OAuth 2.0 servidor de autorización expirará después de la duración proporcionada por el expires_in valor. Cuando caduca un token de acceso, la aplicación debe generar otro JWT, firmarlo y solicitar otro token de acceso.

Códigos de error de JWT

error de campo error_description campo Sentido Cómo resolver
unauthorized_client Unauthorized client or scope in request. Si está intentando utilizar la delegación de todo el dominio, la cuenta de servicio no está autorizada en la Consola de administración del dominio del usuario.

Asegúrese de que la cuenta de servicio está autorizado en los Delegación de dominio en toda la página de la consola de administración para el usuario en el sub reclamo (campo).

Si bien generalmente toma unos minutos, la autorización puede demorar hasta 24 horas en propagarse a todos los usuarios de su cuenta de Google.

unauthorized_client Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested. Se autorizó una cuenta de servicio utilizando la dirección de correo electrónico del cliente en lugar del ID de cliente (numérico) en la Consola de administración. En el dominio de toda la delegación de página en la Consola de administración, quitar el cliente, y volver a agregarlo con la identificación numérica.
access_denied (algún valor) Si usa la delegación de todo el dominio, uno o más ámbitos solicitados no están autorizados en la Consola de administración.

Asegúrese de que la cuenta de servicio está autorizado en los Delegación de dominio en toda la página de la consola de administración para el usuario en el sub reclamo (campo), y que incluye todos los ámbitos que solicita en el scope reclamo de su JWT.

Si bien generalmente toma unos minutos, la autorización puede demorar hasta 24 horas en propagarse a todos los usuarios de su cuenta de Google.

invalid_grant Not a valid email. El usuario no existe. Compruebe que la dirección de correo electrónico en el sub reclamo (campo) es correcta.
invalid_grant

Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe. Check your 'iat' and 'exp' values and use a clock with skew to account for clock differences between systems.

Por lo general, significa que la hora del sistema local no es correcta. También podría suceder si el exp valor es más de 65 minutos en el futuro de la iat valor o la exp valor es inferior a iat valor.

Asegúrese de que el reloj del sistema donde se genera el JWT sea correcto. Si es necesario, sincronizar el tiempo con Google NTP .

invalid_grant Invalid JWT Signature.

La aserción JWT se firma con una clave privada no asociada con la cuenta de servicio identificada por el correo electrónico del cliente o la clave que se usó ha sido eliminada, deshabilitada o vencida.

Alternativamente, la aserción JWT podría estar codificada incorrectamente; debe estar codificada en Base64, sin líneas nuevas ni signos iguales de relleno.

Decodifique el conjunto de notificaciones de JWT y verifique que la clave que firmó la aserción esté asociada con la cuenta de servicio.

Intente utilizar una biblioteca OAuth proporcionada por Google para asegurarse de que el JWT se genere correctamente.

invalid_scope Invalid OAuth scope or ID token audience provided. No se solicitaron ámbitos (lista vacía de ámbitos) o uno de los ámbitos solicitados no existe (es decir, no es válido).

Asegúrese de que el scope reclamo (campo) de la JWT está poblada, y comparar los alcances que contiene los alcances documentados para las API que desea utilizar, para garantizar que no haya errores o errores tipográficos.

Tenga en cuenta que la lista de ámbitos en los scope necesidades pretensión de ser separado por espacios y no por comas.

disabled_client The OAuth client was disabled. La clave utilizada para firmar la aserción JWT está deshabilitada.

Ir a la Google API Console, y bajo IAM y Administración> Cuentas de servicio, permitirá a la cuenta de servicio que contiene el "ID de clave" que se utiliza para firmar la afirmación.

Anexo: autorización de la cuenta de servicio sin OAuth

Con algunas API de Google, puede realizar llamadas API autorizadas utilizando un JWT firmado directamente como un token de portador, en lugar de un token de acceso OAuth 2.0. Cuando esto sea posible, puede evitar tener que realizar una solicitud de red al servidor de autorización de Google antes de realizar una llamada a la API.

Si la API que desea llamar tiene una definición de servicio publicado en el repositorio GitHub Google API , puede hacer llamadas a la API autorizado el uso de un JWT en lugar de un token de acceso. Para hacerlo:

  1. Crear una cuenta de servicio como se describe anteriormente. Asegúrese de conservar el archivo JSON que obtiene cuando crea la cuenta.
  2. El uso de cualquier biblioteca JWT estándar, tal como uno que se encuentra en jwt.io , cree un JWT con una cabecera y la carga útil como el siguiente ejemplo:
    {
      "alg": "RS256",
      "typ": "JWT",
      "kid": "abcdef1234567890"
    }
    .
    {
      "iss": "123456-compute@developer.gserviceaccount.com",
      "sub": "123456-compute@developer.gserviceaccount.com",
      "aud": "https://firestore.googleapis.com/",
      "iat": 1511900000,
      "exp": 1511903600
    }
    • Para el kid en el encabezado, especifique su cuenta de servicio de identificación de la clave privada. Puede encontrar este valor en el private_key_id campo de su servicio de archivo de cuenta JSON.
    • Para los iss y sub campos, especifique la dirección de correo electrónico de su cuenta de servicio. Puede encontrar este valor en el client_email campo de su servicio de archivo de cuenta JSON.
    • Para el aud campo, especifique el punto final de la API. Por ejemplo: https:// SERVICE .googleapis.com/ .
    • Para el iat campo, especifique la hora actual Unix, y para el exp campo, especifique el tiempo exactamente 3.600 segundos más tarde, cuando el JWT expirará.

Firme el JWT con RSA-256 utilizando la clave privada que se encuentra en el archivo JSON de su cuenta de servicio.

Por ejemplo:

Java

Usando google-api-java-cliente y java-JWT :

GoogleCredential credential =
        GoogleCredential.fromStream(new FileInputStream("MyProject-1234.json"));
PrivateKey privateKey = credential.getServiceAccountPrivateKey();
String privateKeyId = credential.getServiceAccountPrivateKeyId();

long now = System.currentTimeMillis();

try {
    Algorithm algorithm = Algorithm.RSA256(null, privateKey);
    String signedJwt = JWT.create()
        .withKeyId(privateKeyId)
        .withIssuer("123456-compute@developer.gserviceaccount.com")
        .withSubject("123456-compute@developer.gserviceaccount.com")
        .withAudience("https://firestore.googleapis.com/")
        .withIssuedAt(new Date(now))
        .withExpiresAt(new Date(now + 3600 * 1000L))
        .sign(algorithm);
} catch ...

Pitón

Usando PyJWT :

iat = time.time()
exp = iat + 3600
payload = {'iss': '123456-compute@developer.gserviceaccount.com',
           'sub': '123456-compute@developer.gserviceaccount.com',
           'aud': 'https://firestore.googleapis.com/',
           'iat': iat,
           'exp': exp}
additional_headers = {'kid': PRIVATE_KEY_ID_FROM_JSON}
signed_jwt = jwt.encode(payload, PRIVATE_KEY_FROM_JSON, headers=additional_headers,
                       algorithm='RS256')
  1. Llamar a la API, utilizando el token de JWT firmado como el portador:
    GET /v1/projects/abc/databases/123/indexes HTTP/1.1
    Authorization: Bearer SIGNED_JWT
    Host: firestore.googleapis.com