Tipos de token

Google Cloud emite vários tipos de tokens, que diferem de acordo com a finalidade e as partes entre as quais eles são trocados.

A tabela a seguir mostra uma visão geral das principais categorias de tokens, em que há diferentes tipos de tokens.

Os tokens de acesso e de identidade são tokens do portador. Os tokens do portador são uma classe geral de token que concede acesso à parte em posse do token.

O uso de tokens do portador para autenticação depende da segurança fornecida por um protocolo criptografado, como HTTPS. Se um token do portador for interceptado, ele poderá ser usado por um usuário de má-fé para conseguir acesso.

Se os tokens do portador não fornecerem segurança suficiente para seu caso de uso, você poderá diminuir o risco de roubo de tokens usando o acesso sensível ao contexto, limitando o ciclo de vida dos tokens de acesso ou usando uma solução de Transport Layer Security mútuo (mTLS), como o Chrome Enterprise Premium.

Tokens de acesso

Os tokens de acesso permitem que os clientes façam chamadas autenticadas para APIs do Google Cloud . OGoogle Cloud aceita vários tipos diferentes de tokens de acesso, que têm as seguintes propriedades em comum:

• Eles autenticam um principal, que pode ser um usuário ou uma carga de trabalho.

• Elas são emitidas para um cliente específico.

• Elas são de curta duração e expiram em algumas horas.

• Eles são restritos a determinados escopos, endpoints ou recursos do OAuth. Isso significa que um token de acesso normalmente não concede acesso a todos os recursos de um usuário, mas apenas a um determinado subconjunto deles.

Os tokens de acesso podem variar das seguintes maneiras:

• Emissor: a parte que emite o token.

• Principal: o tipo de principal que o token pode autenticar.

• Restrições: as restrições que podem ser impostas ao token.

A tabela a seguir lista os diferentes tipos de tokens de acesso:

Os diferentes tipos de tokens de acesso também apresentam propriedades de segurança diferentes:

• Formato: alguns tokens de acesso são opacos, ou seja, estão em um formato reservado e não podem ser inspecionados. Outros tokens são codificados como um JSON Web Token, que pode ser decodificado pelo cliente.

• Introspecção: alguns tokens opacos podem ser introspectados usando a APIGoogle Cloud , enquanto outros não.

• Ciclo de vida: os tokens têm ciclos de vida diferentes e podem ser modificados em graus diferentes.

• Revogabilidade: alguns tokens podem ser revogados. Outros tokens permanecem válidos até a expiração.

A tabela a seguir resume as diferenças entre os tipos de token de acesso.

Tokens de acesso do usuário

Os tokens de acesso do usuário autenticam um usuário e autorizam um cliente a agir em nome dele:

O principal autenticado é uma conta de usuário gerenciada ou uma conta de consumidor. O cliente pode ser um aplicativo da Web ou nativo.

Os tokens de acesso do usuário são opacos. Para fins de diagnóstico, é possível inspecionar um token de acesso usando o seguinte comando, substituindo ACCESS_TOKEN por um token de acesso válido:

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

Esse comando produz um resultado semelhante ao seguinte exemplo:

{
  "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"
}

A saída inclui os seguintes campos:

Os tokens de acesso do usuário expiram automaticamente após uma hora, mas podem ser revogados antes, se necessário.

Por padrão, os tokens de acesso do usuário são tokens do portador, o que significa que eles não estão vinculados a nenhum canal de comunicação, rede ou credencial adicional. Você pode implementar a vinculação de token implantando o acesso baseado em certificado para que os tokens de acesso do usuário só possam ser usados com um certificado de cliente mTLS válido.

Tokens de acesso da conta de serviço

Os tokens de acesso da conta de serviço autenticam uma conta de serviço. Os tokens são opacos, e você pode inspecioná-los usando a API https://oauth2.googleapis.com/tokeninfo.

Para um token de acesso da conta de serviço, a API retorna uma saída semelhante ao exemplo a seguir:

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

Um token de conta de serviço inclui os seguintes campos:

Os tokens de acesso da conta de serviço não podem ser revogados e permanecem válidos até expirarem.

Por padrão, os tokens de acesso da conta de serviço expiram após uma hora. Ao usar o método serviceAccounts.generateAccessToken, é possível solicitar tokens com diferentes tempos de vida. Como ciclos de vida mais longos podem aumentar o risco, configure a restrição iam.allowServiceAccountCredentialLifetimeExtension para permitir que os clientes solicitem tokens de acesso à conta de serviço com ciclos de vida maiores que uma hora.

Tokens de delegação em todo o domínio

Os tokens de delegação em todo o domínio autenticam um usuário e autorizam uma conta de serviço a agir em nome dele. Os tokens são opacos, e você pode fazer a introspecção deles usando a API https://oauth2.googleapis.com/tokeninfo.

Para um token de delegação em todo o domínio, a API retorna uma saída semelhante ao exemplo a seguir:

{
  "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"
}

Um token de delegação em todo o domínio inclui os seguintes campos:

Os tokens de delegação em todo o domínio expiram automaticamente após uma hora e não podem ser revogados.

Tokens da Web JSON da conta de serviço

Os JSON Web Tokens (JWTs) de conta de serviço autenticam uma conta de serviço. Enquanto os tokens de acesso da conta de serviço são emitidos por um servidor de autorização, os JWTs da conta de serviço podem ser emitidos pelo próprio cliente.

Às vezes, eles são chamados de JWTs "autoassinados". Eles podem ser úteis quando você precisa fazer a autenticação em algumas APIs do Google sem receber um token de acesso do servidor de autorização, por exemplo, ao criar suas próprias bibliotecas de cliente.

Para emitir um JWT de conta de serviço, os clientes precisam seguir estas etapas:

1. Prepare um payload de assinatura da Web JSON que inclua o endereço de e-mail da conta de serviço, um escopo do OAuth ou um endpoint de API e um tempo de expiração.

2. Assine o payload usando uma chave de conta de serviço da respectiva conta de serviço. Os clientes podem assinar o payload off-line usando uma chave de conta de serviço gerenciada pelo usuário ou on-line usando o método signJwt e uma chave de conta de serviço gerenciado pelo Google. Para mais informações, consulte Criar um JSON Web Token autoassinado.

Um JWT de conta de serviço decodificado é semelhante ao seguinte, com SIGNATURE substituído pela assinatura do token:

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

Em vez de especificar um escopo do OAuth na chave scope, um JWT de conta de serviço pode especificar um endpoint de API na chave aud:

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

Um JWT de conta de serviço inclui os seguintes campos:

Os JWTs de contas de serviço podem ser válidos por até uma hora e não podem ser revogados.

Tokens de acesso federados

Os tokens de acesso federados autenticam um principal do pool de identidades de colaboradores ou um principal do pool de identidades da carga de trabalho.

A federação de identidade de colaboradores permite que os clientes troquem um token externo por um token de acesso federado que autentica um principal do pool de colaboradores. O principal do pool de identidades de colaboradores é identificado por um identificador principal semelhante a este:

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

A federação de identidade da carga de trabalho permite que os clientes troquem um token externo por um token de acesso federado que autentica um principal do pool de cargas de trabalho. O principal do pool de identidades da carga de trabalho é identificado por um identificador principal semelhante a este:

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

Os tokens de acesso federados são opacos e não podem ser introspectados. Os tokens não podem ser revogados e permanecem válidos até a expiração. As expirações para cada tipo de token são definidas da seguinte forma:

• A federação de identidade da força de trabalho define o vencimento do token como o menor dos dois valores a seguir:

  • Tempo restante até o vencimento da sessão da federação de identidade da força de trabalho

  • 1 hora

  A expiração da sessão da federação de identidade de colaboradores é determinada com base no horário de login e na duração da sessão configurada para o pool da federação de identidade de colaboradores.

• A federação de identidade da carga de trabalho define a expiração do token para que ela corresponda à expiração do token externo.

Tokens de limite de acesso a credenciais

Os tokens de limite de acesso a credenciais autenticam um usuário ou uma conta de serviço e incluem um limite de acesso. O limite de acesso restringe o token para que ele só possa ser usado para acessar um subconjunto definido de recursos do Cloud Storage.

Os tokens de limite de acesso a credenciais às vezes são chamados de com escopo reduzido porque são derivados de um token de entrada, mas são mais restritos nos recursos a que concedem acesso.

A expiração dos tokens de limite de acesso a credenciais é derivada da expiração do token de entrada, que pode ser um token de acesso do usuário ou um token de acesso da conta de serviço. Os tokens de limite de acesso a credenciais são opacos e não podem ser inspecionados ou revogados.

Tokens de limite de acesso a credenciais emitidos pelo cliente

Os tokens de limite de acesso a credenciais emitidos pelo cliente são semelhantes aos tokens de limite de acesso a credenciais, mas são otimizados para cenários em que os clientes precisam obter tokens de limite de acesso a credenciais com diferentes limites de acesso com alta frequência.

Os clientes podem criar tokens de limite de acesso de credenciais emitidas pelo cliente localmente usando as bibliotecas de cliente do Cloud e um token intermediário de limite de acesso, que precisa ser atualizado periodicamente.

Os tokens de limite de acesso a credenciais emitidos pelo cliente são opacos e não podem ser introspeccionados ou revogados.

Tokens de concessão de token

Os tokens de concessão de token permitem que os clientes obtenham tokens novos ou diferentes, possivelmente em um momento posterior.O Google Cloud oferece suporte a vários tipos diferentes de tokens de concessão de token, e todos eles têm o seguinte em comum:

• Eles representam uma autenticação anterior.

• Eles autenticam um principal, que pode ser uma identidade do Google (um usuário ou carga de trabalho) ou uma identidade externa.

• Eles podem ser trocados por um token de acesso.

• Eles não podem ser usados para fazer chamadas de API do Google, o que os diferencia dos tokens de acesso.

Os tokens de concessão de token podem variar das seguintes maneiras:

• Emissor: a parte que emite o token.

• Principal: o tipo de identidade principal que o token pode autenticar.

• Restrições: as restrições que podem ser impostas ao token.

A tabela a seguir lista os diferentes tipos de tokens de concessão de token.

Os diferentes tipos de tokens de concessão também apresentam propriedades de segurança diferentes:

• Formato: alguns tokens são opacos. Outros tokens podem ser decodificados pelo cliente.

• Ciclo de vida: os tokens têm ciclos de vida diferentes e podem ser modificados em graus diferentes.

• Vários usos: alguns tokens de concessão só podem ser usados uma vez. Outros tokens podem ser usados várias vezes.

• Revogabilidade: alguns tokens podem ser revogados. Outros tokens permanecem válidos até a expiração.

A tabela a seguir resume as diferenças entre essas propriedades para tokens de concessão de token:

Tokens de atualização

Os tokens de atualização são tokens opacos que permitem aos clientes obter tokens de ID e de acesso para um usuário, se ele tiver autorizado um cliente a agir em seu nome.

Os tokens de atualização estão vinculados a um cliente específico e só podem ser usados em combinação com credenciais válidas do cliente, por exemplo, um ID do cliente e uma chave secreta do cliente.

Se a autorização do cliente incluir um ou mais Google Cloud escopos do OAuth, o ciclo de vida do token de atualização estará sujeito ao controle de Google Cloud duração da sessão. Caso contrário, os tokens de atualização permanecem válidos até que o usuário revogue a autorização ou outros eventos de revogação de token ocorram.

Códigos de autorização

Os códigos de autorização são tokens opacos e de curta duração. Os códigos devem ser usados apenas durante a autenticação do usuário como um intermediário entre o cliente e o servidor de autorização do Google.

Assim como os tokens de atualização, os códigos de autorização são vinculados a um cliente e só podem ser usados em combinação com credenciais de cliente válidas. Ao contrário dos tokens de atualização, os códigos de autorização só podem ser usados uma vez.

Tokens de atualização federados

Os tokens de atualização federados são opacos e permitem que os clientes obtenham tokens de acesso para um principal do pool de identidades da força de trabalho, se o usuário tiver autorizado um cliente a agir em nome dele.

Assim como os tokens de atualização, os tokens de atualização federados estão vinculados a um cliente específico e só podem ser usados em combinação com credenciais de cliente válidas, como um ID do cliente e uma chave secreta do cliente.

Ao contrário dos tokens de atualização, os tokens de atualização federados não podem ser revogados. O tempo de vida de um token de atualização federado está vinculado à sessão de identidade de colaboradores que foi usada para receber o token e permanece válido até que a sessão expire.

Códigos de autorização federados

Assim como os códigos de autorização, os códigos de autorização federados são tokens opacos e de curta duração. Os códigos devem ser usados apenas durante a autenticação do usuário como um intermediário entre o cliente e o servidor de autorização do Google Cloud IAM.

Os códigos de autorização estão vinculados a um cliente, só podem ser usados com credenciais de cliente válidas e só podem ser usados uma vez.

Declarações de JSON Web Token da conta de serviço

As declarações de JSON Web Tokens (JWTs) de contas de serviço afirmam a identidade de uma conta de serviço. As cargas de trabalho podem usar declarações JWT conta de serviço para receber tokens de acesso de contas de serviço ou tokens de delegação em todo o domínio. A declaração JWT da conta de serviço é assinada por uma chave de conta de serviço.

Uma declaração JWT de conta de serviço decodificada é semelhante a esta, com SIGNATURE substituído pela assinatura do token:

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

As declarações JWT de contas de serviço são estruturalmente semelhantes aos JWTs de contas de serviço: os dois tipos de tokens podem ser emitidos pelo próprio cliente e são assinados por uma chave de conta de serviço. No entanto, os dois tipos de tokens usam payloads diferentes, conforme descrito na tabela a seguir.

As declarações JWT de contas de serviço podem ser válidas por até uma hora e não podem ser revogadas.

Tokens JSON da Web externos

Os JSON Web Tokens (JWTs) externos são emitidos por um provedor de identidade externo, como Microsoft Entra ID, Okta, Kubernetes ou GitHub. Elas podem ter estruturas e conteúdos diferentes.

Ao configurar a federação de identidade de colaboradores ou a federação de identidade de carga de trabalho, você pode estabelecer uma relação de confiança entre Google Cloud e um provedor de identidade externo. As cargas de trabalho podem usar JWTs externos como tokens de concessão de token para receber tokens de acesso federados.

Ao usar a Federação de identidade de colaboradores, o token de acesso federado resultante autentica um principal do pool de identidades de colaboradores.

Ao usar a federação de identidade da carga de trabalho, o token de acesso federado resultante autentica um principal do pool de identidades da carga de trabalho.

Em ambos os casos, o identificador principal é derivado de uma ou mais declarações do JWT externo.

Para serem compatíveis com o Workforce Identity Federation ou a federação de identidade da carga de trabalho, os JWTs externos precisam atender a requisitos específicos.

Declarações ou respostas SAML externas

As declarações externas da Linguagem de marcação para autorização de segurança (SAML) são declarações SAML 2.0 emitidas por um provedor de identidade externo, como o ID do Microsoft Entra, o Okta ou os Serviços de Federação do Active Directory. Essas declarações SAML externas podem ser incluídas em uma resposta SAML 2.0 ou criptografadas.

Assim como com os JSON Web Tokens externos, é possível configurar a Federação de Identidade da Força de Trabalho ou a Federação de Identidade da Carga de Trabalho para que as cargas de trabalho usem declarações ou respostas SAML externas como tokens de concessão de token para receber tokens de acesso federados.

Para serem compatíveis com o Workforce Identity Federation ou a federação de identidade da carga de trabalho, as declarações SAML externas precisam atender a requisitos específicos.

Token do Amazon Web Services (AWS) GetCallerIdentity

Os tokens externos da AWS GetCallerIdentity são blobs de texto que contêm uma solicitação assinada para a API GetCallerIdentity da AWS. Assim como os tokens da Web JSON externos e as declarações SAML, é possível configurar a federação de identidade de colaboradores ou a federação de identidade da carga de trabalho para que as cargas de trabalho usem esses blobs de texto como um token de concessão de token e obtenham tokens de acesso federados.

Tokens de identidade

Os tokens de identidade (ID) permitem que os clientes identifiquem o usuário com quem estão interagindo.O Google Cloud aceita vários tipos diferentes de tokens de identidade, e todos eles têm o seguinte em comum:

• Eles são formatados como JSON Web Tokens (JWTs) para que possam ser decodificados, verificados e interpretados pelo cliente.

• Eles autenticam um principal, que pode ser um usuário ou uma carga de trabalho.

• Elas são emitidas para um cliente específico.

• Eles são de curta duração e expiram após no máximo uma hora.

• Elas não são revogáveis.

• Eles não podem ser usados para fazer chamadas de API do Google, o que os diferencia dos tokens de acesso.

• Eles não podem ser usados para receber tokens de acesso, o que os diferencia dos tokens de concessão de token.

• Eles podem ser usados para autenticar chamadas entre microsserviços ou para autenticação programática no Identity-Aware Proxy (IAP).

Os tokens de identidade podem variar das seguintes maneiras:

• Público-alvo: a parte destinada a decodificar e consumir o token.

• Emissor: a parte que emite o token.

• Ciclo de vida: os tokens têm ciclos de vida diferentes e podem ser modificados em graus diferentes.

• Principal: o tipo de identidade principal que o token pode autenticar.

A tabela a seguir lista os diferentes tipos de tokens de identidade.

Tokens de ID do usuário

Os tokens de ID do usuário são JSON Web Tokens (JWTs) que autenticam um usuário. Os clientes podem receber um token de ID do usuário iniciando um fluxo de autenticação do OIDC.

Os tokens de ID do usuário são assinados usando o conjunto de chaves web JSON (JWKS) do Google. O JWKS do Google é um recurso global, e as mesmas chaves de assinatura são usadas para diferentes tipos de usuários, incluindo:

• Contas de usuário gerenciadas

• Contas de usuário pessoais

• Contas de serviço

Um token de ID do usuário decodificado é semelhante ao seguinte, com SIGNATURE substituído pela assinatura do 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

Um token de ID inclui os seguintes campos:

O conjunto exato de declarações incluídas em um token de ID depende do parâmetro scope na solicitação de autenticação.

Para identificar se um usuário tem uma conta gerenciada ou a conta do Cloud Identity ou do Google Workspace a que ele pertence, os clientes precisam inspecionar a declaração hd.

Os tokens de ID do usuário são válidos por uma hora e não podem ser revogados.

Tokens de ID da conta de serviço

Os tokens de ID da conta de serviço são JSON Web Tokens (JWTs) que autenticam uma conta de serviço.

Ao contrário dos JWTs de contas de serviço e das declarações JWT de contas de serviço, os tokens de ID de contas de serviço não são assinados por uma chave de conta de serviço. Em vez disso, os tokens de ID da conta de serviço são assinados pelo conjunto de chaves da Web JSON (JWKS) do Google.

Um token de ID de conta de serviço decodificado é semelhante ao seguinte, com SIGNATURE substituído pela assinatura do token:

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

Um token de ID da conta de serviço inclui os seguintes campos:

O conjunto exato de declarações incluídas em um token de ID depende da maneira como ele é solicitado. Por exemplo, os tokens de ID solicitados pelo servidor de metadados do Compute Engine podem incluir declarações adicionais que confirmam a identidade da VM. Os tokens de ID solicitados usando a API IAM Credentials podem conter opcionalmente o ID da organização do projeto da conta de serviço.

Ao contrário dos tokens de ID do usuário, os tokens de ID da conta de serviço não oferecem suporte à declaração hd.

Os tokens de ID da conta de serviço são válidos por uma hora e não podem ser revogados.

Declarações do Identity-Aware Proxy

As declarações do Identity-Aware Proxy (IAP) são JSON Web Tokens (JWTs) que o IAP transmite para aplicativos da Web protegidos pelo IAP no cabeçalho da solicitação HTTP x-goog-iap-jwt-assertion. As declarações do IAP autenticam um usuário e também servem como prova de que uma solicitação foi autorizada pelo IAP.

Ao contrário dos tokens de ID do usuário e dos tokens de ID da conta de serviço, as declarações do IAP não são assinadas usando o conjunto de chaves da Web JSON (JWKS) do Google. Em vez disso, as declarações da IAP são assinadas usando um JWKS separado, o JWKS da IAP. Esse JWKS é um recurso global, e as mesmas chaves de assinatura são usadas para diferentes tipos de usuários, incluindo o seguinte:

• Contas de usuário gerenciadas

• Contas pessoais

• Contas de serviço

• Principais do pool de identidade da força de trabalho

Uma declaração de IAP decodificada é semelhante à seguinte, com SIGNATURE substituído pela assinatura do 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

Se você configurar o IAP para usar a federação de identidade de colaboradores em vez de identidades do Google, as declarações do IAP serão um pouco 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

Uma declaração da IAP inclui os seguintes campos:

Para mais detalhes sobre as declarações de asserção do IAP, consulte Como verificar o payload do JWT.

As declarações de IAP são válidas por 10 minutos e não podem ser revogadas.

Declarações SAML

As declarações da Linguagem de marcação para autorização de segurança (SAML) autenticam uma conta de usuário gerenciada e autorizam o acesso a um app SAML personalizado. As declarações SAML são emitidas e assinadas pelo Cloud Identity e só podem ser usadas para autenticar contas de usuário gerenciadas.

Ao contrário dos tokens de ID, que são assinados usando uma chave global, as declarações SAML são assinadas usando uma chave específica de uma conta do Cloud Identity ou do Google Workspace.

Uma declaração de resposta SAML decodificada é semelhante a esta:

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

Uma declaração SAML inclui os seguintes campos:

O conjunto exato de atributos incluídos em uma declaração SAML depende da configuração do app SAML.

As declarações SAML são válidas por 10 minutos e não podem ser revogadas.