Tipos de tokens

Google Cloud emite varios tipos de tokens, que difieren según su propósito y las partes entre las que se intercambian.

En la siguiente tabla, se proporciona una descripción general de las principales categorías de tokens, dentro de las cuales se encuentran diferentes tipos de tokens.

Los tokens de acceso y de identidad son tokens del portador. Los tokens del portador son una clase general de token que otorga acceso a la parte que posee el token.

El uso de tokens del portador para la autenticación se basa en la seguridad proporcionada por un protocolo encriptado, como HTTPS. Si se intercepta un token del portador, una persona que actúa de mala fe puede usarlo para obtener acceso.

Si los tokens del portador no proporcionan suficiente seguridad para tu caso de uso, puedes disminuir el riesgo de robo de tokens con el acceso según el contexto, limitar la vida útil de los tokens de acceso o usar una solución de seguridad de la capa de transporte mutua (mTLS), como Chrome Enterprise Premium.

Tokens de acceso

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

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

• Se emiten para un cliente en particular.

• Son de corta duración y vencen después de unas horas como máximo.

• Están restringidos a ciertos permisos, extremos o recursos de OAuth. Esto significa que, por lo general, un token de acceso no otorga acceso a todos los recursos de un usuario, sino solo a un subconjunto de ellos.

Los tokens de acceso pueden diferir de las siguientes maneras:

• Emisor: Es la parte que emite el token.

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

• Restricciones: Son las restricciones que se pueden imponer en el token.

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

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

• Formato: Algunos tokens de acceso son opacos, lo que significa que están en un formato propio y no se pueden inspeccionar. Otros tokens se codifican como un token web JSON, que el cliente puede decodificar.

• Introspección: Algunos tokens opacos se pueden introspeccionar con la API deGoogle Cloud , mientras que otros no.

• Duración: Los tokens difieren en su duración y en el grado en que se pueden modificar.

• Revocabilidad: Algunos tokens se pueden revocar. Los demás tokens seguirán siendo válidos hasta su vencimiento.

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

Tokens de acceso del usuario

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

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

Los tokens de acceso del usuario son opacos. Para fines de diagnóstico, puedes inspeccionar un token de acceso con el siguiente comando, reemplazando ACCESS_TOKEN por un token de acceso válido:

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

Este comando produce un resultado similar al 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"
}

El resultado incluye los siguientes campos:

Los tokens de acceso de usuario vencen automáticamente después de una hora, pero se pueden revocar antes si es necesario.

De forma predeterminada, los tokens de acceso del usuario son tokens del portador, lo que significa que no están vinculados a ningún canal de comunicación, red o credencial adicional en particular. De manera opcional, puedes implementar la vinculación de tokens implementando el acceso basado en certificados para que los tokens de acceso del usuario solo se puedan usar junto con un certificado de cliente de mTLS válido.

Tokens de acceso de cuentas de servicio

Los tokens de acceso de la cuenta de servicio autentican una cuenta de servicio. Los tokens son opacos y puedes introspeccionarlos con la API de 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 la cuenta de servicio no se pueden revocar y permanecen válidos hasta que vencen.

De forma predeterminada, los tokens de acceso de la cuenta de servicio vencen después de una hora. Con el método serviceAccounts.generateAccessToken, puedes solicitar tokens con diferentes períodos de vigencia. Dado que las vidas útiles más largas de los tokens 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 vidas útiles 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 a actuar en nombre del usuario. Los tokens son opacos y puedes introspeccionarlos con la API de https://oauth2.googleapis.com/tokeninfo.

En el caso de un token de delegación para todo el dominio, la API devuelve un resultado similar al 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 para todo el dominio incluye los siguientes campos:

Los tokens de delegación en todo el dominio vencen automáticamente después de una hora y no se pueden revocar.

Tokens web JSON de cuentas de servicio

Los tokens web JSON (JWT) de la cuenta de servicio autentican una cuenta de servicio. Mientras que los tokens de acceso de la cuenta de servicio son emitidos por un servidor de autorización, los JWT de la cuenta de servicio pueden ser emitidos por el propio cliente.

A veces, se los denomina JWT "autofirmados". Pueden ser útiles cuando necesitas autenticarte en algunas APIs de Google sin obtener un token de acceso del servidor de autorización, por ejemplo, cuando creas tus propias bibliotecas 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 alcance de OAuth o un extremo de API, y una hora de vencimiento.

2. Firma la carga útil con una clave de cuenta de servicio de la cuenta de servicio respectiva. Los clientes pueden firmar la carga útil sin conexión con una clave de cuenta de servicio administrada por el usuario o en línea con el método signJwt y una clave de cuenta de servicio administrada por Google. Para obtener más información, consulta Crea un token web JSON autofirmado.

Un JWT de cuenta de servicio decodificado se ve similar al siguiente, con SIGNATURE reemplazado 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 alcance de OAuth en la clave scope, un JWT de cuenta de servicio puede especificar un extremo 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 hasta por una hora y no se pueden revocar.

Tokens de acceso federado

Los tokens de acceso federado autentican a un principal de grupo de cargas de trabajo o a un principal de grupo de personal.

La federación de identidades de personal permite que los clientes intercambien un token externo por un token de acceso federado que autentica a una principal del grupo de personal. El principal del grupo de identidades para cargas de trabajo se identifica con un identificador principal similar al siguiente:

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

La federación de Workload Identity permite que los clientes intercambien un token externo por un token de acceso federado que autentica a una principal del grupo de cargas de trabajo. El principal del grupo de identidades para cargas de trabajo se identifica con un identificador principal similar al siguiente:

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

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

• La federación de identidades de personal establece el vencimiento del token según la configuración del proveedor del grupo de identidades de personal.

• La federación de Workload Identity establece el vencimiento del token para que coincida con el vencimiento del token externo.

Tokens de límite de acceso a las credenciales

Los tokens de límite de acceso a 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 las credenciales se denominan de alcance reducido porque se derivan de un token de entrada, pero son más restringidos en los recursos a los que otorgan acceso.

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

Tokens de límites de acceso a las credenciales emitidos por el cliente

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

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

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

Tokens de otorgamiento de tokens

Los tokens de concesión de tokens permiten que los clientes obtengan tokens nuevos o diferentes, posiblemente en un momento posterior. 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 previa.

• Autentican a una 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 realizar llamadas a las APIs de Google, lo que las distingue de los tokens de acceso.

Los tokens de concesión de tokens pueden diferir de las siguientes maneras:

• Emisor: Es la parte que emite el token.

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

• Restricciones: Son las restricciones que se pueden imponer en el 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 también exhiben diferentes propiedades de seguridad:

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

• Duración: Los tokens difieren en su duración y en el grado en que se pueden modificar.

• Uso múltiple: Algunos tokens de concesión solo se pueden usar una vez. Otros tokens se pueden usar varias veces.

• Revocabilidad: Algunos tokens se pueden revocar. Los demás tokens seguirán siendo válidos hasta su vencimiento.

En la siguiente tabla, se resumen las diferencias entre estas propiedades para los tokens de concesión de 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 para un usuario, si este autorizó previamente a un cliente a actuar 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, por ejemplo, un ID de cliente y un secreto del cliente.

Si la autorización del cliente incluye uno o más permisos de OAuthGoogle Cloud , la vida útil del token de actualización está sujeta al control de 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 del usuario 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.

Confirmaciones de token web JSON de la cuenta de servicio

Las aserciones de los tokens web JSON (JWT) de la cuenta de servicio confirman la identidad de una cuenta de servicio. Las cargas de trabajo pueden usar aserciones de 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 del JWT de la cuenta de servicio está firmada por una clave de cuenta de servicio.

Una aserción JWT de cuenta de servicio decodificada se ve similar a la siguiente, con SIGNATURE reemplazado 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 de JWT de cuentas de servicio son estructuralmente similares a los JWT de cuentas de servicio: ambos tipos de tokens pueden ser emitidos por el cliente y están firmados por una clave de cuenta de servicio. Sin embargo, los dos tipos de tokens usan diferentes cargas útiles, como se describe en la siguiente tabla.

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

Tokens web JSON externos

Los tokens web JSON (JWT) externos son emitidos por un proveedor de identidad externo, como Microsoft Entra ID, Okta, Kubernetes o GitHub. Pueden diferir en su estructura y contenido.

Si configuras la federación de Workforce Identity o la federación de Workload Identity, puedes establecer una relación de confianza entre Google Cloud y un proveedor de identidad externo. Luego, las cargas de trabajo pueden usar los JWT externos como tokens de concesión de tokens para obtener tokens de acceso federado.

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

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

En ambos casos, el identificador principal se deriva de una o más reclamaciones del JWT externo.

Para que sean compatibles con la federación de identidades del personal o la federación de identidades para cargas de trabajo, los JWT externos deben satisfacer requisitos específicos.

Aserciones o respuestas de SAML externas

Las aserciones externas del lenguaje de marcado de confirmación de seguridad (SAML) son aserciones de SAML 2.0 que emite un proveedor de identidad externo, como Microsoft Entra ID, Okta o Active Directory Federation Services. Estas aserciones de SAML externas se pueden incluir de forma opcional en una respuesta de SAML 2.0 o encriptarse.

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

Para ser compatibles con la federación de identidades del personal de trabajo o la federación de identidades para cargas de trabajo, las aserciones de SAML externas deben satisfacer requisitos específicos.

Token de Amazon Web Services (AWS) GetCallerIdentity

Los tokens externos de AWS GetCallerIdentity son BLOB de texto que contienen una solicitud firmada a la API de GetCallerIdentity de AWS. Al igual que con los tokens web JSON externos y las aserciones de SAML, puedes configurar la federación de identidades para la fuerza laboral o la federación de identidades para cargas de trabajo de modo que las cargas de trabajo puedan usar estos objetos binarios grandes de texto como un token de concesión de tokens para obtener tokens de acceso federados.

Tokens de identidad

Los tokens de ID permiten que los clientes identifiquen al usuario con el que interactúan. Google Cloud admite varios tipos diferentes de tokens de ID, y todos tienen lo siguiente en común:

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

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

• Se emiten para un cliente en particular.

• Son de corta duración y vencen después de una hora como máximo.

• No se pueden revocar.

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

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

• Se pueden usar para autenticar llamadas entre microservicios o para autenticarse de forma programática en Identity-Aware Proxy (IAP).

Los tokens de identidad pueden diferir de las siguientes maneras:

• Público: Es la parte que debe decodificar y consumir el token.

• Emisor: Es la parte que emite el token.

• Duración: Los tokens difieren en su duración y en el grado en que se pueden modificar.

• Principal: Es 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 tokens web JSON (JWT) que autentican a un usuario. Los clientes pueden obtener un token de ID del usuario iniciando un flujo de autenticación de OIDC.

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

• Cuentas de usuario administradas

• Cuentas de usuario personales

• Cuentas de servicio

Un token de ID de usuario decodificado se ve similar al siguiente, con SIGNATURE reemplazado 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 un usuario es una cuenta de usuario administrada o para identificar la cuenta de Cloud Identity o Google Workspace a la que pertenece un usuario, los clientes deben inspeccionar el reclamo hd.

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

Tokens de ID de cuentas de servicio

Los tokens de ID de cuentas de servicio son tokens web JSON (JWT) que autentican una cuenta de servicio.

A diferencia de los JWT de cuentas de servicio y las aserciones de 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 cambio, los tokens de ID de la cuenta de servicio están firmados por el conjunto de claves web JSON (JWKS) de Google.

Un token de ID de cuenta de servicio decodificado se ve similar al siguiente, con SIGNATURE reemplazado 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 solicita el token de ID. Por ejemplo, los tokens de ID solicitados por el servidor de metadatos de Compute Engine pueden incluir de forma opcional declaraciones adicionales que afirman la identidad de la VM. Los tokens de ID solicitados con la API de IAM Credentials pueden contener, de manera opcional, el ID de la 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 el reclamo hd.

Los tokens de ID de la 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 (JWT) que IAP pasa 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 autorizó una solicitud.

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

• Cuentas de usuario administradas

• Cuentas personales

• Cuentas de servicio

• Principales del grupo de identidades del personal

Una aserción de IAP decodificada es similar a la siguiente, con SIGNATURE reemplazado 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 usar la federación de identidades de personal en lugar de identidades de Google, las confirmaciones de IAP se verán un poco 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 IAP incluye los siguientes campos:

Para obtener más detalles sobre las declaraciones de la aserción de IAP, consulta Cómo verificar la carga útil de JWT.

Las confirmaciones de IAP son válidas durante 10 minutos y no se pueden revocar.

Aserciones de SAML

Las aserciones del lenguaje de marcado para confirmaciones de seguridad (SAML) autentican una cuenta de usuario administrada y la autorizan a acceder a una app de SAML personalizada. Cloud Identity emite y firma las aserciones de SAML, y solo se pueden usar para autenticar cuentas de usuario administradas.

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

Una aserción de respuesta de SAML decodificada se ve de la siguiente manera:

<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 de SAML depende de la configuración de la app de SAML.

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