Tipos de token

A maioria dos tokens de acesso e identidade são tokens do portador. Os tokens do portador concedem acesso à parte que está de posse do token, independentemente 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, o cliente precisa fornecer uma prova adicional de que é o proprietário legítimo do token. Portanto, os tokens vinculados são mais restritivos do que os tokens do 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 as APIs do Cloud de Confiance by S3NS . OCloud de Confiance by S3NS oferece suporte a 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.

• Eles são emitidos para um cliente específico.

• Eles têm vida curta e expiram após algumas horas, no máximo.

• Elas são restritas 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 ser diferentes 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, o que significa que 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 diferem no ciclo de vida e na medida em que podem ser modificados.
• Revogabilidade: alguns tokens podem ser revogados. Outros tokens permanecem válidos até expirarem.
• 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 de 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 durações. Como ciclos de vida de token mais longos podem aumentar o risco, é necessário configurar a restrição iam.allowServiceAccountCredentialLifetimeExtension para permitir que os clientes solicitem tokens de acesso de conta de serviço com ciclos de vida maiores que uma hora.

JSON Web Tokens da conta de serviço

Os JSON Web Tokens (JWTs) de conta de serviço são tokens do 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 se autenticar 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 endpoint de API e um expiry time.

2. Assine o payload usando uma chave 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.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.s3nsapis.fr/",
  "exp": 1744854799,
  "iat": 1744851199
}.SIGNATURE

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

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

Tokens de acesso federado

Os tokens de acesso federados são tokens do portador que autenticam um principal do pool de identidade de colaboradores ou um principal do pool de identidade 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 Identidade 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 inspecionados. Os tokens não podem ser revogados e permanecem válidos até expirarem. As expirações para cada tipo de token são definidas da seguinte maneira:

• A federação de identidade de colaboradores define a validade do token como o menor dos dois valores a seguir:

  • Tempo restante até que a sessão da federação de identidade de colaboradores expire

  • 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 validade do token para que ela corresponda à validade do token externo.

Tokens de acesso de identidade do agente

Os tokens de acesso de identidade de agente autenticam um agente que recebeu uma identidade de agente e usam um identificador principal semelhante ao seguinte:

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 do cliente X.509 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 do cliente X.509. Um token de acesso de identidade de agente vinculado só é válido quando usado em uma conexão TLS mútua autenticada com o certificado do cliente X.509 ao qual o token foi vinculado.

Assim como os tokens de acesso federados, os tokens de acesso de identidade do agente são opacos, não podem ser inspecionados 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 vinculada a um certificado do cliente X.509 que está próximo da validade.

Tokens de limite de acesso a credenciais

Os tokens de limite de acesso de credenciais são tokens do portador que 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 escopo reduzido porque são derivados de um token de entrada, mas são mais restritos nos recursos a que concedem acesso.

A validade dos tokens de limite de acesso de credenciais é derivada da validade 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 ou revogados.

Tokens de limite de acesso de credenciais emitidos pelo cliente

Os tokens de limite de acesso de credenciais emitidos pelo cliente são semelhantes aos tokens de limite de acesso de credenciais, mas são otimizados para cenários em que os clientes precisam receber tokens de limite de acesso de credenciais com diferentes limites de acesso em 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 de credenciais emitidos pelo cliente são opacos e não podem ser inspecionados ou revogados.

Tokens de concessão de token

Os tokens de concessão de token permitem que os clientes recebam 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:

• Eles representam uma autenticação anterior.

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

• Eles podem ser resgatados 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 ser diferentes 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 exibem propriedades de segurança diferentes:

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

• Ciclo de vida: os tokens diferem no ciclo de vida e na medida em que podem ser modificados.

• Uso múltiplo: alguns tokens de concessão de token 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é expirarem.

• 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 do 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 tokens opacos que permitem que os clientes recebam tokens de acesso para um principal do pool de identidades de colaboradores, se o usuário tiver autorizado anteriormente 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. A vida útil de um token de atualização federado está vinculada à sessão de identidade de colaboradores que foi usada para receber o token e permanece válida 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 intermediário entre o cliente e o servidor de autorização do IAM do Cloud de Confiance by S3NS .

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

JSON Web Tokens externos

Os JSON Web Tokens (JWTs) externos são emitidos por um provedor de identidade externo, como Microsoft Entra ID, Okta, Kubernetes ou GitHub. Eles podem ser diferentes em estrutura e conteúdo.

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

Quando você usa a federação de identidade de colaboradores, o token de acesso federado resultante autentica um principal do pool de identidades de colaboradores.

Quando você usa a federação de identidade da carga de trabalho, o token de acesso federado resultante autentica um principal do pool de identidades de 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 Microsoft Entra ID, 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 nos JSON Web Tokens 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 GetCallerIdentity da Amazon Web Services (AWS)

Os tokens externos da AWS GetCallerIdentity são blobs de texto que contêm uma solicitação assinada para a API GetCallerIdentity da AWS. Semelhante aos JSON Web Tokens 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 possam usar 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.

• Eles são emitidos para um cliente específico.

• Eles têm vida curta e expiram após no máximo uma hora.

• Eles 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 de maneira programática no Identity-Aware Proxy (IAP).

Os tokens de identidade podem ser diferentes das seguintes maneiras:

• Público-alvo: a parte que deve 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 exibem propriedades de segurança diferentes:

• Formato: alguns tokens são JSON Web Tokens (JWT), outros usam a 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 token de identidade.

Tokens de ID da conta de serviço

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

Ao contrário dos JWTs de conta de serviço e das declarações de JWT de conta de serviço, os tokens de ID de conta 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, na sigla em inglês) 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 de 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 afirmam a identidade da VM. Os tokens de ID solicitados usando a API IAM Credentials podem conter 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 do cliente X.509. Um token de ID de identidade de agente vinculado contém a impressão digital do certificado do cliente X.509 na declaração cnf.

Ao contrário dos tokens de ID do usuário e dos tokens de ID da conta de serviço, os tokens de ID de identidade do agente não são assinados pelo conjunto de chaves Web JSON (JWKS) do Google. Em vez disso, os tokens de ID de identidade de agente são assinados por um JWKS específico de um pool de identidades de agente.

Um token de ID de identidade de 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 de colaboradores

Uma declaração do IAP decodificada é semelhante ao 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 do IAP inclui os seguintes campos:

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

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