Tipos de tokens

Google Cloud emite varios tipos de tokens, que se diferencian por su finalidad y por las partes entre las que se intercambian.

En la siguiente tabla se ofrece un resumen de las principales categorías de tokens, dentro de las cuales se encuentran los diferentes tipos de tokens.

Los tokens de acceso y de identidad son tokens de portador. Los tokens de portador son una clase general de tokens que conceden acceso a la parte que los posee.

Para usar tokens de portador en la autenticación, se necesita un protocolo cifrado, como HTTPS. Si se intercepta un token de portador, un agente pernicioso puede usarlo para obtener acceso.

Si los tokens de portador no proporcionan suficiente seguridad para tu caso práctico, puedes reducir el riesgo de robo de tokens usando acceso contextual, limitando la duración de los tokens de acceso o usando una solución de seguridad de la capa de transporte (TLS) mutua, como Chrome Enterprise Premium.

Tokens de acceso

Los tokens de acceso permiten que los clientes hagan llamadas autenticadas a las APIs de Google Cloud . Google Cloud admite varios tipos de tokens de acceso, que tienen las siguientes propiedades en común:

• Autentican una entidad principal, que puede ser un usuario o una carga de trabajo.

• Se emiten para un cliente concreto.

• Son de corta duración y caducan al cabo de unas horas como máximo.

• Están restringidas a determinados permisos de OAuth, endpoints o recursos. Esto significa que, por lo general, un token de acceso no concede acceso a todos los recursos de un usuario, sino solo a un subconjunto de ellos.

Los tokens de acceso pueden diferir en los siguientes aspectos:

• Emisor: la parte que emite el token.

• Principal: el tipo de principal que puede autenticar el token.

• Restricciones: las restricciones que se pueden imponer al token.

En la siguiente tabla se enumeran los diferentes tipos de tokens de acceso:

Los distintos tipos de tokens de acceso también tienen diferentes propiedades de seguridad:

• Formato: algunos tokens de acceso son opacos, lo que significa que tienen un formato propietario y no se pueden inspeccionar. Otros tokens se codifican como JSON Web Token, que el cliente puede decodificar.

• Introspección: algunos tokens opacos se pueden introspeccionar mediante la APIGoogle Cloud , mientras que otros no.

• Tiempo de vida: los tokens se diferencian en el tiempo de vida y en el grado en que se pueden modificar.

• Revocabilidad: algunos tokens se pueden revocar. Los demás tokens siguen siendo válidos hasta su fecha de vencimiento.

En la siguiente tabla se resumen las diferencias entre los tipos de token de acceso.

Tokens de acceso de usuario

Los tokens de acceso de usuario autentican a un usuario y autorizan a un cliente a actuar en nombre del usuario:

La entidad principal autenticada es una cuenta de usuario gestionada o una cuenta de consumidor. El cliente puede ser una aplicación web o una aplicación nativa.

Los tokens de acceso de usuario son opacos. Para fines de diagnóstico, puedes introspeccionar un token de acceso mediante el siguiente comando. Sustituye ACCESS_TOKEN por un token de acceso válido:

curl "https://oauth2.googleapis.com/tokeninfo?access_token=ACCESS_TOKEN"

Este comando genera un resultado similar al del siguiente ejemplo:

{
  "azp": "0000000000.apps.googleusercontent.com",
  "aud": "0000000000.apps.googleusercontent.com",
  "sub": "00000000000000000000",
  "scope": "openid https://www.googleapis.com/auth/userinfo.email",
  "exp": "1744687132",
  "expires_in": "3568",
  "email": "user@example.com",
  "email_verified": "true"
}

La salida incluye los siguientes campos:

Los tokens de acceso de usuario caducan automáticamente al cabo de una hora, pero se pueden revocar antes si es necesario.

De forma predeterminada, los tokens de acceso de usuario son tokens de portador, lo que significa que no están vinculados a ningún canal de comunicación, red ni credencial adicional. También puedes implementar el enlace de tokens mediante la implementación del acceso basado en certificados para que los tokens de acceso de los usuarios solo se puedan usar junto con un certificado de cliente mTLS válido.

Tokens de acceso de cuentas de servicio

Los tokens de acceso de cuentas de servicio autentican una cuenta de servicio. Los tokens son opacos y puedes introspeccionarlos mediante la API https://oauth2.googleapis.com/tokeninfo.

En el caso de un token de acceso de cuenta de servicio, la API devuelve un resultado similar al siguiente ejemplo:

{
  "azp": "000000000000000000000",
  "aud": "000000000000000000000",
  "scope": "https://www.googleapis.com/auth/userinfo.email",
  "exp": "1744687132",
  "expires_in": "3568",
  "email": "service-account@example.iam.gserviceaccount.com",
  "email_verified": "true",
  "access_type": "online"
}

Un token de cuenta de servicio incluye los siguientes campos:

Los tokens de acceso de las cuentas de servicio no se pueden revocar y siguen siendo válidos hasta que caducan.

De forma predeterminada, los tokens de acceso de la cuenta de servicio caducan al cabo de una hora. Con el método serviceAccounts.generateAccessToken, puedes solicitar tokens con diferentes tiempos de validez. Como los tiempos de vida de los tokens más largos pueden aumentar el riesgo, debes configurar la restricción iam.allowServiceAccountCredentialLifetimeExtension para permitir que los clientes soliciten tokens de acceso de cuentas de servicio con tiempos de vida superiores a una hora.

Tokens de delegación de todo el dominio

Los tokens de delegación de todo el dominio autentican a un usuario y autorizan a una cuenta de servicio para que actúe en nombre del usuario. Los tokens son opacos y puedes introspeccionarlos mediante la API https://oauth2.googleapis.com/tokeninfo.

En el caso de un token de delegación de todo el dominio, la API devuelve un resultado similar al del siguiente ejemplo:

{
  "azp": "000000000000000000000",
  "aud": "000000000000000000000",
  "scope": "https://www.googleapis.com/auth/admin.directory.user.readonly https://www.googleapis.com/auth/userinfo.email",
  "exp": "1744688957",
  "expires_in": "3540",
  "email": "user@example.com",
  "email_verified": "true",
  "access_type": "offline"
}

Un token de delegación de todo el dominio incluye los siguientes campos:

Los tokens de delegación de todo el dominio caducan automáticamente al cabo de una hora y no se pueden revocar.

JSON Web Tokens de cuentas de servicio

Los JSON Web Tokens (JWTs) de las cuentas de servicio autentican una cuenta de servicio. Mientras que los tokens de acceso de la cuenta de servicio los emite un servidor de autorización, los JWTs de la cuenta de servicio los puede emitir el propio cliente.

A veces se denominan JWTs "autofirmados". Pueden ser útiles cuando necesites autenticarte en algunas APIs de Google sin obtener un token de acceso del servidor de autorización, por ejemplo, al crear tus propias bibliotecas de cliente.

Para emitir un JWT de cuenta de servicio, los clientes deben seguir estos pasos:

1. Prepara una carga útil de firma web JSON que incluya la dirección de correo electrónico de la cuenta de servicio, un ámbito de OAuth o un endpoint de API, y un tiempo de vencimiento.

2. Firma la carga útil con una clave de cuenta de servicio de la cuenta de servicio correspondiente. Los clientes pueden firmar la carga útil sin conexión mediante una clave de cuenta de servicio gestionada por el usuario o con conexión mediante el método signJwt y una clave de cuenta de servicio gestionada por Google. Para obtener más información, consulta Crear un JSON Web Token autofirmado.

Un JWT de cuenta de servicio decodificado tiene un aspecto similar al siguiente, con SIGNATURE sustituido por la firma del token:

{
  "alg": "RS256",
  "kid": "290b7bf588eee0c35d02bf1164f4336229373300",
  "typ": "JWT"
}.{
  "iss": "service-account@example.iam.gserviceaccount.com",
  "sub": "service-account@example.iam.gserviceaccount.com",
  "scope": "https://www.googleapis.com/auth/cloud-platform",
  "exp": 1744851267,
  "iat": 1744850967
}.SIGNATURE

En lugar de especificar un ámbito de OAuth en la clave scope, un JWT de cuenta de servicio puede especificar un endpoint de API en la clave aud:

{
  "alg": "RS256",
  "kid": "290b7bf588eee0c35d02bf1164f4336229373300",
  "typ": "JWT"
}.{
  "iss": "service-account@example.iam.gserviceaccount.com",
  "sub": "service-account@example.iam.gserviceaccount.com",
  "aud": "https://cloudresourcemanager.googleapis.com/",
  "exp": 1744854799,
  "iat": 1744851199
}.SIGNATURE

Un JWT de cuenta de servicio incluye los siguientes campos:

Los JWTs de cuentas de servicio pueden ser válidos durante un máximo de una hora y no se pueden revocar.

Tokens de acceso federados

Los tokens de acceso federado autentican una entidad de un grupo de cargas de trabajo o una entidad de un grupo de Workforce.

Workforce Identity Federation permite a los clientes intercambiar un token externo por un token de acceso federado que autentica a una entidad de un grupo de trabajo. El principal del grupo de identidades de carga de trabajo se identifica mediante un identificador principal similar al siguiente:

principal://iam.googleapis.com/locations/global/workforcePools/POOL/subject/raha@altostrat.com.

La federación de identidades de cargas de trabajo permite a los clientes intercambiar un token externo por un token de acceso federado que autentica a una entidad de seguridad de un grupo de cargas de trabajo. El principal del grupo de identidades de carga de trabajo se identifica mediante un identificador principal similar al siguiente:

principal://iam.googleapis.com/projects/PROJECT/locations/global/workloadIdentityPools/POOL/subject/SUBJECT_ATTRIBUTE_VALUE

Los tokens de acceso federados son opacos y no se pueden introspeccionar. Los tokens no se pueden revocar y siguen siendo válidos hasta que caduquen. Los vencimientos de cada tipo de token se basan en lo siguiente:

• La federación de identidades de los trabajadores define el vencimiento del token en función de la configuración del proveedor del grupo de identidades de los trabajadores.

• La federación de identidades de cargas de trabajo define la caducidad del token para que coincida con la del token externo.

Tokens de límite de acceso a credenciales

Los tokens de límite de acceso de las credenciales autentican a un usuario o una cuenta de servicio y incluyen un límite de acceso. El límite de acceso restringe el token para que solo se pueda usar para acceder a un subconjunto definido de recursos de Cloud Storage.

A veces, los tokens de límite de acceso a credenciales se denominan de ámbito reducido porque se derivan de un token de entrada, pero tienen más restricciones en cuanto a los recursos a los que conceden acceso.

La caducidad de los tokens de límite de acceso de las credenciales se deriva de la caducidad del token de entrada, que puede ser un token de acceso de usuario o un token de acceso de cuenta de servicio. Los tokens de límite de acceso a las credenciales son opacos y no se pueden inspeccionar ni revocar.

Tokens de límite de acceso de credenciales emitidos por el cliente

Los tokens de límite de acceso de credenciales emitidas por el cliente son similares a los tokens de límite de acceso de credenciales, pero están optimizados para situaciones en las que los clientes necesitan obtener tokens de límite de acceso de credenciales con diferentes límites de acceso con una frecuencia alta.

Los clientes pueden crear tokens de límite de acceso de credenciales emitidas por el cliente de forma local mediante las bibliotecas de cliente de Cloud y un token intermediario de límite de acceso, que deben actualizar periódicamente.

Los tokens de límite de acceso de credenciales emitidas por el cliente son opacos y no se pueden introspeccionar ni revocar.

Tokens de concesión de tokens

Los tokens de concesión de tokens permiten a los clientes obtener tokens nuevos o diferentes, posiblemente en otro momento. Google Cloud admite varios tipos diferentes de tokens de concesión de tokens, y todos tienen lo siguiente en común:

• Representan una autenticación anterior.

• Autentican una entidad principal, que puede ser una identidad de Google (un usuario o una carga de trabajo) o una identidad externa.

• Se pueden canjear por un token de acceso.

• No se pueden usar para hacer llamadas a las APIs de Google, lo que las diferencia de los tokens de acceso.

Los tokens de concesión de tokens pueden diferir en los siguientes aspectos:

• Emisor: la parte que emite el token.

• Principal: el tipo de identidad principal que puede autenticar el token.

• Restricciones: las restricciones que se pueden imponer al token.

En la siguiente tabla se enumeran los diferentes tipos de tokens de concesión de tokens.

Los diferentes tipos de tokens de concesión de tokens también tienen diferentes propiedades de seguridad:

• Formato: algunos tokens son opacos. El cliente puede decodificar otros tokens.

• Tiempo de vida: los tokens tienen un tiempo de vida diferente y se pueden modificar en mayor o menor medida.

• Multiuso: algunos tokens que conceden tokens solo se pueden usar una vez. Otros tokens se pueden usar varias veces.

• Revocabilidad: algunos tokens se pueden revocar. Los demás tokens siguen siendo válidos hasta su fecha de vencimiento.

En la siguiente tabla se resumen las diferencias entre estas propiedades para los tokens que conceden tokens:

Tokens de actualización

Los tokens de actualización son tokens opacos que permiten a los clientes obtener tokens de ID y tokens de acceso de un usuario si este ha autorizado previamente a un cliente para que actúe en su nombre.

Los tokens de actualización están vinculados a un cliente específico y solo se pueden usar en combinación con credenciales de cliente válidas, como un ID de cliente y un secreto de cliente.

Si la autorización del cliente incluye uno o varios Google Cloud ámbitos de OAuth, la duración del token de actualización está sujeta al control de la Google Cloud duración de la sesión. De lo contrario, los tokens de actualización seguirán siendo válidos hasta que el usuario revoque su autorización o se produzcan otros eventos de revocación de tokens.

Códigos de autorización

Los códigos de autorización son tokens opacos de corta duración. Los códigos solo se deben usar durante la autenticación de usuarios como intermediarios entre el cliente y el servidor de autorización de Google.

Al igual que los tokens de actualización, los códigos de autorización están vinculados a un cliente y solo se pueden usar en combinación con credenciales de cliente válidas. A diferencia de los tokens de actualización, los códigos de autorización solo se pueden usar una vez.

Aserciones de JSON Web Token de cuentas de servicio

Las aserciones de JSON Web Token (JWT) de cuentas de servicio afirman la identidad de una cuenta de servicio. Las cargas de trabajo pueden usar aserciones JWT de cuentas de servicio para obtener tokens de acceso de cuentas de servicio o tokens de delegación de todo el dominio. La aserción JWT de la cuenta de servicio está firmada por una clave de cuenta de servicio.

Una aserción JWT de cuenta de servicio decodificada tiene un aspecto similar al siguiente, donde SIGNATURE se sustituye por la firma del token:

{
  "alg": "RS256",
  "kid": "290b7bf588eee0c35d02bf1164f4336229373300",
  "typ": "JWT"
}.{
  "iss": "service-account@example.iam.gserviceaccount.com",
  "scope": "https://www.googleapis.com/auth/devstorage.read_only",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1744851267,
  "iat": 1744850967
}.SIGNATURE

Las aserciones JWT de cuentas de servicio son estructuralmente similares a los JWTs de cuentas de servicio: ambos tipos de tokens pueden ser emitidos por el propio cliente y están firmados por una clave de cuenta de servicio. Sin embargo, los dos tipos de tokens usan cargas útiles diferentes, tal como se describe en la siguiente tabla.

Las aserciones JWT de cuentas de servicio pueden ser válidas hasta una hora y no se pueden revocar.

JSON Web Tokens externos

Los JSON Web Tokens (JWTs) externos los emite un proveedor de identidades externo, como Microsoft Entra ID, Okta, Kubernetes o GitHub. Pueden diferir en su estructura y contenido.

Si configuras Workforce Identity Federation o Workload Identity Federation, puedes establecer una relación de confianza entre Google Cloud y un proveedor de identidades externo. Las cargas de trabajo pueden usar JWTs externos como tokens de concesión de tokens para obtener tokens de acceso federado.

Cuando usas Workforce Identity Federation, el token de acceso federado resultante autentica a un principal del grupo de identidades de empleados.

Cuando usas la federación de identidades de cargas de trabajo, el token de acceso federado resultante autentica un principal del grupo de identidades de cargas de trabajo.

En ambos casos, el identificador de la entidad principal se deriva de una o varias reclamaciones del JWT externo.

Para que sean compatibles con la federación de identidades de trabajo o de cargas de trabajo, los JWTs externos deben cumplir requisitos específicos.

Aserciones o respuestas SAML externas

Las aserciones lenguaje de marcado para confirmaciones de seguridad (SAML) externas son aserciones SAML 2.0 emitidas por un proveedor de identidades externo, como Microsoft Entra ID, Okta o Servicios de federación de Active Directory. Estas aserciones SAML externas se pueden incluir de forma opcional en una respuesta SAML 2.0 o cifrarse.

Al igual que con los JSON Web Tokens externos, puedes configurar la federación de identidades de Workforce o la federación de identidades de cargas de trabajo para que las cargas de trabajo puedan usar aserciones o respuestas SAML externas como tokens de concesión de tokens para obtener tokens de acceso federados.

Para que sean compatibles con la federación de identidades de Workforce o la federación de identidades de cargas de trabajo, las aserciones SAML externas deben cumplir requisitos específicos.

Token de GetCallerIdentityAmazon Web Services (AWS)

Los tokens de GetCallerIdentityAWS externos son blobs de texto que contienen una solicitud firmada a la API de GetCallerIdentityAWS. Al igual que con los JSON Web Tokens y las aserciones SAML externos, puedes configurar la federación de identidades de Workforce o la federación de identidades de cargas de trabajo para que las cargas de trabajo puedan usar estos blobs de texto como token de concesión de tokens para obtener tokens de acceso federados.

Tokens de identidad

Los tokens de identidad (ID) permiten a los clientes identificar al usuario con el que están interactuando. Google Cloud admite varios tipos de tokens de identidad, y todos tienen lo siguiente en común:

• Tienen el formato de tokens web JSON (JWTs) para que el cliente pueda decodificarlos, verificarlos e interpretarlos.

• Autentican una entidad principal, que puede ser un usuario o una carga de trabajo.

• Se emiten para un cliente concreto.

• Son de corta duración y caducan al cabo de una hora como máximo.

• No se pueden revocar.

• No se pueden usar para hacer llamadas a las APIs de Google, lo que las diferencia de los tokens de acceso.

• No se pueden usar para obtener tokens de acceso, lo que los diferencia de los tokens de concesión de tokens.

• Se pueden usar para autenticar llamadas entre microservicios o para autenticarse mediante programación en Identity-Aware Proxy (IAP).

Los tokens de identidad pueden diferir en los siguientes aspectos:

• Audiencia: la parte que debe decodificar y consumir el token.

• Emisor: la parte que emite el token.

• Tiempo de vida: los tokens tienen un tiempo de vida diferente y se pueden modificar en mayor o menor medida.

• Principal: el tipo de identidad principal que puede autenticar el token.

En la siguiente tabla se enumeran los diferentes tipos de tokens de identidad.

Tokens de ID de usuario

Los tokens de ID de usuario son JSON Web Tokens (JWTs) que autentican a un usuario. Los clientes pueden obtener un token de ID de usuario iniciando un flujo de autenticación de OIDC.

Los tokens de ID de usuario se firman con el conjunto de claves web de JSON (JWKS) de Google. El JWKS de Google es un recurso global y se usan las mismas claves de firma para diferentes tipos de usuarios, incluidos los siguientes:

• Cuentas de usuario gestionadas

• Cuentas de usuario de consumidor

• Cuentas de servicio

Un token de ID de usuario decodificado tiene un aspecto similar al siguiente, con SIGNATURE sustituido por la firma del token:

{
  "alg": "RS256",
  "kid": "c37da75c9fbe18c2ce9125b9aa1f300dcb31e8d9",
  "typ": "JWT"
}.{
  "iss": "https://accounts.google.com",
  "azp": "1234567890-123456789abcdef.apps.googleusercontent.com",
  "aud": "1234567890-123456789abcdef.apps.googleusercontent.com",
  "sub": "12345678901234567890",
  "at_hash": "y0LZEe-ervzRNSxn4R-t9w",
  "name": "Example user",
  "picture": "https://lh3.googleusercontent.com/a/...",
  "given_name": "Example",
  "family_name": "User",
  "hd": "example.com",
  "iat": 1745361695,
  "exp": 1745365295
}.SIGNATURE

Un token de ID incluye los siguientes campos:

El conjunto exacto de reclamaciones incluidas en un token de ID depende del parámetro scope de la solicitud de autenticación.

Para identificar si una cuenta de usuario es gestionada o a qué cuenta de Cloud Identity o Google Workspace pertenece, los clientes deben inspeccionar la reclamación hd.

Los tokens de ID de usuario son válidos durante una hora y no se pueden revocar.

Tokens de ID de cuenta de servicio

Los tokens de ID de cuenta de servicio son JSON Web Tokens (JWTs) que autentican una cuenta de servicio.

A diferencia de los JWTs de cuentas de servicio y las aserciones JWT de cuentas de servicio, los tokens de ID de cuentas de servicio no están firmados por una clave de cuenta de servicio. En su lugar, los tokens de ID de la cuenta de servicio están firmados por el conjunto de claves web de JSON (JWKS) de Google.

Un token de ID de cuenta de servicio decodificado tiene un aspecto similar al siguiente, con SIGNATURE sustituido por la firma del token:

{
  "alg": "RS256",
  "kid": "c37da75c9fbe18c2ce9125b9aa1f300dcb31e8d9",
  "typ": "JWT"
}.{
  "aud": "example-audience",
  "azp": "112010400000000710080",
  "email": "service-account@example.iam.gserviceaccount.com",
  "email_verified": true,
  "exp": 1745365618,
  "iat": 1745362018,
  "iss": "https://accounts.google.com",
  "sub": "112010400000000710080"
}.SIGNATURE

Un token de ID de cuenta de servicio incluye los siguientes campos:

El conjunto exacto de reclamaciones incluidas en un token de ID depende de la forma en que se solicite el token de ID. Por ejemplo, los tokens de ID solicitados por el servidor de metadatos de Compute Engine pueden incluir de forma opcional reclamaciones adicionales que afirmen la identidad de la VM. Los tokens de ID solicitados mediante la API IAM Credentials pueden incluir opcionalmente el ID de organización del proyecto de la cuenta de servicio.

A diferencia de los tokens de ID de usuario, los tokens de ID de cuenta de servicio no admiten la reclamación hd.

Los tokens de ID de cuenta de servicio son válidos durante una hora y no se pueden revocar.

Aserciones de Identity-Aware Proxy

Las aserciones de Identity-Aware Proxy (IAP) son tokens web JSON (JWTs) que IAP transfiere a las aplicaciones web protegidas por IAP en el encabezado de solicitud HTTP x-goog-iap-jwt-assertion. Las aserciones de IAP autentican a un usuario y también sirven como prueba de que IAP ha autorizado una solicitud.

A diferencia de los tokens de ID de usuario y los tokens de ID de cuenta de servicio, las aserciones de IAP no se firman con el conjunto de claves web JSON (JWKS) de Google. En su lugar, las aserciones de IAP se firman con un JWKS independiente, el JWKS de IAP. Este JWKS es un recurso global y se usan las mismas claves de firma para diferentes tipos de usuarios, incluidos los siguientes:

• Cuentas de usuario gestionadas

• Cuentas de consumidor

• Cuentas de servicio

• Principales de grupos de identidades de Workforce

Una aserción de IAP decodificada tiene un aspecto similar al siguiente, donde SIGNATURE se sustituye por la firma del token:

{
  "alg": "ES256",
  "typ": "JWT",
  "kid": "4BCyVw"
}.{
  "aud": "/projects/0000000000/global/backendServices/000000000000",
  "azp": "/projects/0000000000/global/backendServices/000000000000",
  "email": "user@example.com",
  "exp": 1745362883,
  "google": {
    "access_levels": [
      "accessPolicies/0000000000/accessLevels/Australia"
    ]
  },
  "hd": "example.com",
  "iat": 1745362283,
  "identity_source": "GOOGLE",
  "iss": "https://cloud.google.com/iap",
  "sub": "accounts.google.com:112010400000000710080"
}.SIGNATURE

Si configuras IAP para que use la federación de identidades de Workforce en lugar de las identidades de Google, las aserciones de IAP serán ligeramente diferentes:

{
  "alg": "ES256",
  "typ": "JWT",
  "kid": "4BCyVw"
}.{
  "aud": "/projects/0000000000/global/backendServices/000000000000",
  "azp": "/projects/0000000000/global/backendServices/000000000000",
  "email": "user@example.com",
  "exp": 1745374290,
  "google": {
    "access_levels": [
      "accessPolicies/0000000000/accessLevels/Australia"
    ]
  },
  "iat": 1745373690,
  "identity_source": "WORKFORCE_IDENTITY",
  "iss": "https://cloud.google.com/iap",
  "sub": "sts.google.com:AAFTZ...Q",
  "workforce_identity": {
    "iam_principal": "principal://iam.googleapis.com/locations/global/workforcePools/example/subject/user-0000000000",
    "workforce_pool_name": "locations/global/workforcePools/example"
  }
}.SIGNATURE

Una aserción de compra en la aplicación incluye los siguientes campos:

Para obtener más información sobre las reclamaciones de aserción de IAP, consulta Verificar la carga útil del JWT.

Las aserciones de compras en aplicaciones son válidas durante 10 minutos y no se pueden revocar.

Aserciones SAML

Las aserciones del lenguaje de marcado para confirmaciones de seguridad (SAML) autentican una cuenta de usuario gestionada y le autorizan a acceder a una aplicación SAML personalizada. Cloud Identity emite y firma las aserciones SAML, que solo se pueden usar para autenticar cuentas de usuario gestionadas.

A diferencia de los tokens de ID, que se firman con una clave global, las aserciones SAML se firman con una clave específica de una cuenta de Cloud Identity o Google Workspace.

Una aserción de respuesta SAML decodificada tiene un aspecto similar al siguiente:

<saml2:Assertion
  xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="..."
  IssueInstant="2025-04-23T22:47:20.881Z"
  Version="2.0">
  <saml2:Issuer>
    https://accounts.google.com/o/saml2?idpid=C0123456789
  </saml2:Issuer>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
  <saml2:Subject>
    <saml2:NameID
      Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
        user@example.com
    </saml2:NameID>
    <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml2:SubjectConfirmationData
        NotOnOrAfter="2025-04-23T22:52:20.881Z"
        Recipient="https://app.example.com/"/>
    </saml2:SubjectConfirmation>
  </saml2:Subject>

  <saml2:Conditions
    NotBefore="2025-04-23T22:42:20.881Z"
    NotOnOrAfter="2025-04-23T22:52:20.881Z">
    <saml2:AudienceRestriction>
      <saml2:Audience>example-app</saml2:Audience>
    </saml2:AudienceRestriction>
  </saml2:Conditions>

  <saml2:AuthnStatement
    AuthnInstant="2025-04-23T22:46:44.000Z"
    SessionIndex="...">
    <saml2:AuthnContext>
      <saml2:AuthnContextClassRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
      </saml2:AuthnContextClassRef>
    </saml2:AuthnContext>
  </saml2:AuthnStatement>
</saml2:Assertion>

Una aserción SAML incluye los siguientes campos:

El conjunto exacto de atributos incluidos en una aserción SAML depende de la configuración de la aplicación SAML.

Las aserciones SAML son válidas durante 10 minutos y no se pueden revocar.