Tipos de tokens

Cloud de Confiance by S3NS emite vários tipos de tokens, que diferem pela respetiva finalidade e pelas partes entre as quais são trocados.

A tabela seguinte apresenta uma vista geral das principais categorias de tokens, nas quais existem diferentes tipos de tokens.

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

A utilização de tokens de portador para autenticação baseia-se na segurança fornecida por um protocolo encriptado, como o HTTPS. Se um token de portador for intercetado, pode ser usado por um interveniente malicioso para obter acesso.

Se os tokens de portador não oferecerem segurança suficiente para o seu exemplo de utilização, pode diminuir o risco de roubo de tokens através do acesso sensível ao contexto, limitando a duração total dos tokens de acesso ou usando uma solução de protocolo Transport Layer Security (TLS) mútuo, como o Chrome Enterprise Premium.

Tokens de acesso

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

• Autenticam um principal, que pode ser um utilizador ou uma carga de trabalho.

• São emitidos para um cliente específico.

• São de curta duração e expiram após, no máximo, algumas horas.

• Estão restritas a determinados âmbitos, pontos finais ou recursos de OAuth. Isto significa que um token de acesso normalmente não concede acesso a todos os recursos de um utilizador, mas apenas a um determinado subconjunto dos mesmos.

Os tokens de acesso podem diferir das seguintes formas:

• 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 seguinte apresenta os diferentes tipos de tokens de acesso:

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

• Formato: alguns tokens de acesso são opacos, o que significa que estão num formato exclusivo e não podem ser inspecionados. Outros tokens são codificados como um símbolo da Web JSON, que pode ser descodificado pelo cliente.

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

• Revogabilidade: alguns tokens podem ser revogados. Os outros tokens permanecem válidos até à data de validade.

A tabela seguinte resume as diferenças entre os tipos de tokens de acesso.

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.

Para uma chave de acesso da conta de serviço, a API devolve um resultado semelhante ao exemplo seguinte:

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

Não é possível revogar as chaves de acesso da conta de serviço, que permanecem válidas até expirarem.

Por predefinição, os tokens de acesso da conta de serviço expiram após uma hora. Ao usar o método serviceAccounts.generateAccessToken, pode pedir tokens com diferentes durações. Uma vez que os tempos de vida dos tokens mais longos podem aumentar o risco, tem de configurar a restrição iam.allowServiceAccountCredentialLifetimeExtension para permitir que os clientes peçam tokens de acesso da conta de serviço com tempos de vida superiores a uma hora.

Símbolos da Web JSON da conta de serviço

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

Por vezes, estes são denominados JWTs "autossinados". Podem ser úteis quando precisa de se autenticar em algumas APIs Google sem obter um token de acesso do servidor de autorização, por exemplo, quando cria as suas próprias bibliotecas cliente.

Para emitir um JWT de conta de serviço, os clientes têm de efetuar os seguintes passos:

1. Prepare uma carga útil de assinatura Web JSON que inclua o endereço de email da conta de serviço, um âmbito do OAuth ou um ponto final da API e um prazo de validade.

2. Assine a carga útil com uma chave de conta de serviço da respetiva conta de serviço. Os clientes podem assinar o payload offline através de uma chave de conta de serviço gerida pelo utilizador ou online através do método signJwt e de uma chave de conta de serviço gerida pela Google. Para mais informações, consulte o artigo Crie um símbolo da Web JSON autoassinado

Um JWT de conta de serviço descodificado tem um aspeto 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 âmbito do OAuth na chave scope, um JWT de conta de serviço pode especificar um ponto final da 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 durante um máximo de uma hora e não podem ser revogados.

Tokens de acesso federados

Os tokens de acesso federados autenticam um principal do grupo do Workforce Identity ou um principal do Workload Identity Pool.

A federação de identidade da força de trabalho permite que os clientes troquem um token externo por um token de acesso federado que autentica um principal do Workload Identity Pool. O principal do Workload Identity Pool é identificado por um identificador principal semelhante ao seguinte:

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

A Workload Identity Federation permite que os clientes troquem um token externo por um token de acesso federado que autentica um principal do Workload Identity Pool. O principal do Workload Identity Pool é identificado por um identificador principal semelhante ao seguinte:

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

As chaves de acesso federadas são opacas e não podem ser inspecionadas. Não é possível revogar os tokens, que permanecem válidos até à data de validade. Os prazos de validade de cada tipo de token são definidos da seguinte forma:

• A federação de identidade da força de trabalho define a expiração do token para o menor dos seguintes dois valores:

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

  • 1 hora

  O prazo de validade da sessão da federação de identidade da força de trabalho é determinado com base na hora de início de sessão e na duração da sessão configurada para o conjunto da federação de identidade da força de trabalho.

• A federação de identidade da carga de trabalho define a validade do token de forma a corresponder à validade do token externo.

Tokens de limite de acesso de credenciais

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

Os tokens de limite de acesso de credenciais são por vezes referidos como com âmbito reduzido, porque são derivados de um token de entrada, mas são mais restritos nos recursos aos quais concedem acesso.

A expiração das chaves de acesso do limite de acesso das credenciais é derivada da expiração da chave de entrada, que é uma chave de acesso da conta de serviço. Os tokens do limite de acesso às credenciais são opacos e não podem ser inspecionados nem 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 de obter tokens de limite de acesso de credenciais com limites de acesso diferentes com alta frequência.

Os clientes podem criar tokens de limite de acesso de credenciais emitidas pelo cliente localmente através das bibliotecas de cliente da Google Cloud e de um token intermediário de limite de acesso, que têm de atualizar periodicamente.

Os tokens de limite de acesso de credenciais emitidos pelo cliente são opacos e não podem ser analisados nem revogados.

Tokens de concessão de tokens

Os tokens de concessão de tokens permitem que os clientes obtenham tokens novos ou diferentes, possivelmente mais tarde. Cloud de Confiance by S3NS suporta vários tipos diferentes de tokens de concessão de tokens, e todos têm o seguinte em comum:

• Representam uma autenticação anterior.

• Autenticam um principal, que pode ser uma identidade Google (um utilizador ou uma carga de trabalho) ou uma identidade externa.

• Podem ser trocados por um token de acesso.

• Não podem ser usadas para fazer chamadas à API Google, o que as distingue dos tokens de acesso.

Os tokens de concessão de tokens podem diferir das seguintes formas:

• 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 seguinte indica os diferentes tipos de tokens de concessão de tokens.

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

• Formato: alguns tokens são opacos. O cliente pode descodificar outros tokens.

• Duração: os tokens diferem na duração e na medida em que podem ser modificados.

• Várias utilizações: alguns tokens de concessão de tokens só podem ser usados uma vez. Outros tokens podem ser usados várias vezes.

• Revogabilidade: alguns tokens podem ser revogados. Os outros tokens permanecem válidos até à data de validade.

A tabela seguinte resume as diferenças entre estas propriedades para tokens de concessão de tokens:

Tokens de atualização federados

Os tokens de atualização federados são tokens opacos que permitem aos clientes obter tokens de acesso para um principal do Workload Identity Pool, se o utilizador tiver autorizado anteriormente um cliente a agir em seu nome.

Tal como os tokens de atualização, os tokens de atualização federados estão associados a um cliente específico e só podem ser usados em combinação com credenciais de cliente válidas, por exemplo, um ID de cliente e um segredo do cliente.

Ao contrário dos tokens de atualização, não é possível revogar os tokens de atualização federados. A duração de um token de atualização federado está associada à sessão de identidade da força de trabalho que foi usada para obter o token e permanece válida até a sessão expirar.

Códigos de autorização federados

Tal como os códigos de autorização, os códigos de autorização federados são tokens opacos de curta duração. Os códigos destinam-se apenas a ser usados durante a autenticação do utilizador como intermediário entre o cliente e o Cloud de Confiance by S3NS servidor de autorizações do IAM.

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

Símbolos da Web JSON externos

Os tokens da Web JSON (JWTs) externos são emitidos por um fornecedor de identidade externo, como o Microsoft Entra ID, o Okta, o Kubernetes ou o GitHub. Podem diferir na respetiva estrutura e conteúdo.

Ao configurar a federação de identidade da força de trabalho ou a federação de identidade da carga de trabalho, pode configurar uma relação de confiança entre Cloud de Confiance by S3NS e um fornecedor de identidade externo. Em seguida, as cargas de trabalho podem usar JWTs externos como tokens de concessão de tokens para obter tokens de acesso federados.

Quando usa a federação de identidade da força de trabalho, o token de acesso federado resultante autentica um principal do conjunto do Workload Identity da força de trabalho.

Quando usa a federação de identidades de cargas de trabalho, o token de acesso federado resultante autentica um principal do conjunto do Workload Identity de carga de trabalho.

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

Para serem compatíveis com a federação de identidade da força de trabalho ou a federação de identidade da carga de trabalho, os JWTs externos têm de cumprir requisitos específicos.

Respostas ou afirmações SAML externas

As afirmações externas da Linguagem de marcação de afirmações de segurança (SAML) são afirmações SAML 2.0 emitidas por um fornecedor de identidades externo, como o Microsoft Entra ID, o Okta ou os Serviços de federação do Active Directory. Estas afirmações SAML externas podem, opcionalmente, ser incluídas numa resposta SAML 2.0 ou ser encriptadas.

Tal como acontece com os símbolos da Web JSON externos, pode configurar a federação de identidades da força de trabalho ou a federação de identidades da carga de trabalho para que as cargas de trabalho possam usar afirmações ou respostas SAML externas como tokens de concessão de tokens para obter tokens de acesso federados.

Para serem compatíveis com a federação de identidade da força de trabalho ou a federação de identidade da carga de trabalho, as declarações SAML externas têm de cumprir requisitos específicos.

Símbolo GetCallerIdentity do Amazon Web Services (AWS)

Os tokens GetCallerIdentity da AWS externos são blobs de texto que contêm um pedido assinado à API GetCallerIdentity da AWS. Semelhante aos símbolos da Web JSON externos, pode 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 possam usar estes blobs de texto como um símbolo de concessão de símbolos para obter símbolos de acesso federados.

Tokens de identidade

Os tokens de identidade (ID) permitem que os clientes identifiquem o utilizador com o qual estão a interagir. Cloud de Confiance by S3NS suporta vários tipos diferentes de tokens de identidade, e todos têm o seguinte em comum:

• Estão formatados como Símbolos da Web JSON (JWTs) para que possam ser descodificados, validados e interpretados pelo cliente.

• Autenticam um principal, que pode ser um utilizador ou uma carga de trabalho.

• São emitidos para um cliente específico.

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

• Não são revogáveis.

• Não podem ser usadas para fazer chamadas à API Google, o que as distingue dos tokens de acesso.

• Não podem ser usadas para obter chaves de acesso, o que as distingue das chaves de concessão de tokens.

• Podem ser usadas para autenticar chamadas entre microsserviços ou para autenticar programaticamente no Identity-Aware Proxy (IAP).

Os tokens de identidade podem diferir das seguintes formas:

• Público-alvo: a parte que se destina a descodificar e consumir o token.

• Emissor: a parte que emite o token.

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

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

A tabela seguinte apresenta os diferentes tipos de tokens de identidade.

Símbolos de ID da conta de serviço

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

Ao contrário dos JWTs de contas de serviço e das afirmaçõ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 alternativa, os tokens de ID da conta de serviço são assinados pelo conjunto de chaves Web JSON (JWKS) da Google.

Um token de ID de conta de serviço descodificado tem um aspeto 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 reivindicações incluídas num token de ID depende da forma como o token de ID é pedido. Por exemplo, os tokens de ID pedidos pelo servidor de metadados do Compute Engine podem incluir opcionalmente reivindicações adicionais que afirmam a identidade da VM. Os tokens de ID pedidos através da API IAM Credentials podem, opcionalmente, 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 durante uma hora e não podem ser revogados.

Afirmações do Identity-Aware Proxy

As afirmações do Identity-Aware Proxy (IAP) são tokens da Web JSON (JWTs) que o IAP transmite às aplicações Web protegidas pelo IAP no cabeçalho do pedido HTTP x-goog-iap-jwt-assertion. As afirmações de IAP autenticam um utilizador e também servem como prova de que um pedido foi autorizado pelo IAP.

• Contas de utilizador geridas

• Contas de consumidor

• Contas de serviço

• Principais do Workload Identity Pool

Uma declaração de IAP descodificada é 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 afirmação de IAP inclui os seguintes campos:

Para mais detalhes sobre as reivindicações de declaração de IAP, consulte o artigo Validar a carga útil do JWT.

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