Tipos de token

Cloud de Confiance by S3NS 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 de 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 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 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 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 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 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.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. Usando 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 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. 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 gerenciada 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 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 maneira:

• 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 é 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 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 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 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 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 são destinados apenas ao uso 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, você pode 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 de 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, é 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 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 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.

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

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.