Tipos de token

A maioria dos tokens de acesso e de identidade são tokens de portador. Os tokens do portador concedem acesso à parte em posse do token, independente de como ele foi obtido. Se um usuário de má-fé interceptar um token do portador, ele poderá usá-lo para conseguir acesso não autorizado.

Os tokens vinculados concedem acesso a um cliente específico. Para usar um token vinculado, um cliente precisa apresentar mais provas de que é o proprietário legítimo do token. Portanto, os tokens vinculados são mais restritivos do que os de portador e podem ajudar a reduzir o risco de roubo de tokens.

Tokens de acesso

Os tokens de acesso permitem que os clientes façam chamadas autenticadas para APIs do Cloud de Confiance by S3NS . OCloud de Confiance by S3NS 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.
• Ciclo de vida: os tokens têm ciclos de vida diferentes e podem ser modificados em graus variados.
• Revogabilidade: alguns tokens podem ser revogados. Outros tokens permanecem válidos até a expiração.
• Vinculação: alguns tokens podem ser vinculados a uma credencial adicional, o que os torna tokens vinculados.

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

Tokens de acesso da conta de serviço

Os tokens de acesso da conta de serviço são tokens do portador que autenticam uma conta de serviço. Os tokens são opacos.

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.s3ns.iam.gserviceaccount.com",
  "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 da Web JSON da conta de serviço

Os JSON Web Tokens (JWTs) de contas de serviço são tokens de portador que 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 expiry time.

2. Assine o payload usando uma chave de conta de serviço da respectiva conta. 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.s3ns.iam.gserviceaccount.com",
  "sub": "service-account@example.s3ns.iam.gserviceaccount.com",
  "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.s3ns.iam.gserviceaccount.com",
  "sub": "service-account@example.s3ns.iam.gserviceaccount.com",
  "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 são tokens de portador que autenticam um principal do pool de identidades de colaboradores ou um principal do pool de identidades da carga de trabalho.

Com a federação de identidade de colaboradores, os clientes podem trocar 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.

Com a federação de identidade da carga de trabalho, os clientes podem trocar um token externo por um token de acesso federado que autentica um principal do pool de carga 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 de cada tipo de token são definidas da seguinte maneira:

• A federação de identidade de colaboradores 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 de colaboradores

  • 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 acesso à identidade do agente

Os tokens de acesso de identidade do agente autenticam um agente que recebeu uma identidade de agente e usam um identificador principal semelhante a este:

principal://agents.global.org-ORGANIZATION_ID.system.id.goog/resources/aiplatform/projects/PROJECT_NUMBER/locations/us-central1/reasoningEngines/REASONING_ENGINE_ID

O identificador principal é baseado no ID SPIFFE do certificado X.509 do cliente do agente, mas usa o prefixo principal:// em vez de spiffe://.

Um agente pode receber um token de acesso de identidade do agente no servidor de metadados do Compute Engine. Opcionalmente, o agente pode solicitar que o token seja vinculado ao certificado X.509 do cliente. Um token de acesso de identidade do agente vinculado só é válido quando usado em uma conexão TLS mútua autenticada com o certificado X.509 do cliente a que o token foi vinculado.

Assim como os tokens de acesso federado, os tokens de acesso à identidade do agente são opacos, não podem ser introspectados ou revogados e permanecem válidos até a expiração. Por padrão, os tokens de acesso de identidade do agente são válidos por uma hora, mas a validade de um token pode ser menor quando ele está vinculado a um certificado de cliente X.509 que está perto do vencimento.

Tokens de limite de acesso a credenciais

Os tokens de limite de acesso a credenciais são tokens do portador que autenticam um usuário ou 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 é 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 nem 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 emitidos 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 Cloud de Confiance by S3NS oferece suporte a vários tipos diferentes de tokens de concessão de token, e todos eles têm o seguinte em comum:

• Elas 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 de token 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.

• Vinculação: alguns tokens são vinculados a uma credencial adicional, o que os torna tokens vinculados. Outros tokens não são vinculados, o que os torna tokens de portador.

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

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 Cloud de Confiance by S3NS 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.

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 da carga de trabalho, é possível estabelecer uma relação de confiança entre Cloud de Confiance by S3NS 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 a federação de identidade de colaboradores 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 tokens da Web JSON externos, é 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 declarações ou respostas SAML externas como tokens de concessão de token para receber tokens de acesso federados.

Para serem compatíveis com a federação de identidade de colaboradores 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, é 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 para receber 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 Cloud de Confiance by S3NS aceita vários tipos diferentes de tokens de identidade, e todos eles têm o seguinte em comum:

• Eles são assinados, mas não criptografados, 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 autenticar programaticamente 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.

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

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

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

• Formato: alguns tokens são JSON Web Tokens (JWT), outros usam formatação XML.

• Ciclo de vida: os tokens têm ciclos de vida diferentes.

• Vinculação: alguns tokens podem ser vinculados a uma credencial adicional, o que os torna tokens vinculados.

A tabela a seguir resume as diferenças entre os tipos de tokens de identidade.

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.s3ns.iam.gserviceaccount.com",
  "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.

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

Tokens de ID de identidade do agente

Os tokens de ID de identidade do agente são documentos de identidade verificáveis do SPIFFE (JWT-SVID) e autenticam um agente que recebeu uma identidade de agente.

Um agente pode receber um token de ID do servidor de metadados do Compute Engine. Opcionalmente, o agente pode solicitar que o token seja vinculado ao certificado X.509 do cliente. Um token de ID de identidade do agente vinculado contém a impressão digital do certificado do cliente X.509 e só é válido quando usado em uma conexão TLS mútua autenticada com o mesmo certificado do cliente X.509.

Ao contrário dos tokens de ID de usuário e dos tokens de ID de conta de serviço, os tokens de ID de identidade do agente não são assinados pelo conjunto de chaves da Web JSON (JWKS) do Google e não podem ser verificados.

Um token de ID de identidade do agente decodificado é semelhante ao seguinte, com SIGNATURE substituído pela assinatura do token:

{
  "alg": "RS256",
  "kid": "78ab40e4a0319f9ced58024f5bb66e6387d68066",
  "typ": "JWT"
}.{
  "iss": "https://sts.googleapis.com/v1/organizations/1234567890/locations/global/workloadIdentityPools/agents.global.org-1234567890.system.id.goog",
  "sub": "spiffe://agents.global.org-1234567890.system.id.goog/resources/aiplatform/projects/1234567890/locations/us-central1/reasoningEngines/987654321",
  "aud": ["https://example.com/"],
  "iat": 1775776191,
  "exp": 1775779791,
  "cnf": {
    "x5t#S256": "QTB5TSHeDxHrzDzcrrHU+/shhkfCnARcBEvMldp2uis"
  }
}.SIGNATURE

Um token de ID de identidade do agente inclui os seguintes campos:

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.

• 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": 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.