Tipos de tokens

Cloud de Confiance by S3NS emite varios tipos de tokens, que difieren según su propósito y las partes entre las que se intercambian.

En la siguiente tabla, se proporciona una descripción general de las principales categorías de tokens, dentro de las cuales se encuentran diferentes tipos de tokens.

Los tokens de acceso y de identidad son tokens del portador. Los tokens del portador son una clase general de token que otorga acceso a la parte que posee el token.

El uso de tokens del portador para la autenticación se basa en la seguridad proporcionada por un protocolo encriptado, como HTTPS. Si se intercepta un token del portador, una persona que actúa de mala fe puede usarlo para obtener acceso.

Si los tokens del portador no proporcionan suficiente seguridad para tu caso de uso, puedes disminuir el riesgo de robo de tokens con el acceso según el contexto, limitar la vida útil de los tokens de acceso o usar una solución de seguridad de la capa de transporte mutua (mTLS), como Chrome Enterprise Premium.

Tokens de acceso

Los tokens de acceso permiten que los clientes realicen llamadas autenticadas a las APIs de Cloud de Confiance by S3NS . Cloud de Confiance by S3NS admite varios tipos diferentes de tokens de acceso, que tienen las siguientes propiedades en común:

• Autentican una principal, que puede ser un usuario o una carga de trabajo.

• Se emiten para un cliente en particular.

• Son de corta duración y vencen después de unas horas como máximo.

• Están restringidos a ciertos permisos, extremos o recursos de OAuth. Esto significa que, por lo general, un token de acceso no otorga acceso a todos los recursos de un usuario, sino solo a un subconjunto de ellos.

Los tokens de acceso pueden diferir de las siguientes maneras:

• Emisor: Es la parte que emite el token.

• Principal: Es el tipo de principal que el token puede autenticar.

• Restricciones: Son las restricciones que se pueden imponer en el token.

En la siguiente tabla, se enumeran los diferentes tipos de tokens de acceso:

Los diferentes tipos de tokens de acceso también exhiben diferentes propiedades de seguridad:

• Formato: Algunos tokens de acceso son opacos, lo que significa que están en un formato propio y no se pueden inspeccionar. Otros tokens se codifican como un token web JSON, que el cliente puede decodificar.

• Duración: Los tokens difieren en su duración y en el grado en que se pueden modificar.

• Revocabilidad: Algunos tokens se pueden revocar. Los demás tokens seguirán siendo válidos hasta su vencimiento.

En la siguiente tabla, se resumen las diferencias entre los tipos de tokens de acceso.

Tokens de acceso de cuentas de servicio

Los tokens de acceso de la cuenta de servicio autentican una cuenta de servicio. Los tokens son opacos.

En el caso de un token de acceso de cuenta de servicio, la API devuelve un resultado similar al siguiente ejemplo:

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

Un token de cuenta de servicio incluye los siguientes campos:

Los tokens de acceso de la cuenta de servicio no se pueden revocar y permanecen válidos hasta que vencen.

De forma predeterminada, los tokens de acceso de la cuenta de servicio vencen después de una hora. Con el método serviceAccounts.generateAccessToken, puedes solicitar tokens con diferentes períodos de vigencia. Dado que las vidas útiles más largas de los tokens pueden aumentar el riesgo, debes configurar la restricción iam.allowServiceAccountCredentialLifetimeExtension para permitir que los clientes soliciten tokens de acceso de cuentas de servicio con vidas útiles superiores a una hora.

Tokens web JSON de cuentas de servicio

Los tokens web JSON (JWT) de la cuenta de servicio autentican una cuenta de servicio. Mientras que los tokens de acceso de cuentas de servicio son emitidos por un servidor de autorización, los JWT de cuentas de servicio pueden ser emitidos por el propio cliente.

A veces, se los denomina JWT "autofirmados". Pueden ser útiles cuando necesitas autenticarte en algunas APIs de Google sin obtener un token de acceso del servidor de autorización, por ejemplo, cuando creas tus propias bibliotecas cliente.

Para emitir un JWT de cuenta de servicio, los clientes deben seguir estos pasos:

1. Prepara una carga útil de firma web JSON que incluya la dirección de correo electrónico de la cuenta de servicio, un alcance de OAuth o un extremo de API, y una hora de vencimiento.

2. Firma la carga útil con una clave de cuenta de servicio de la cuenta de servicio respectiva. Los clientes pueden firmar la carga útil sin conexión con una clave de cuenta de servicio administrada por el usuario o en línea con el método signJwt y una clave de cuenta de servicio administrada por Google. Para obtener más información, consulta Crea un token web JSON autofirmado.

Un JWT de cuenta de servicio decodificado se ve similar al siguiente, con SIGNATURE reemplazado por la firma del 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

En lugar de especificar un alcance de OAuth en la clave scope, un JWT de cuenta de servicio puede especificar un extremo de API en la clave 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

Un JWT de cuenta de servicio incluye los siguientes campos:

Los JWTs de cuentas de servicio pueden ser válidos hasta por una hora y no se pueden revocar.

Tokens de acceso federado

Los tokens de acceso federado autentican a un principal del grupo de identidad de personal o a un principal del grupo de identidad para cargas de trabajo.

La federación de identidades de personal permite que los clientes intercambien un token externo por un token de acceso federado que autentica a una principal del grupo de personal. El principal del grupo de identidades del personal se identifica con un identificador principal similar al siguiente:

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

La federación de Workload Identity permite que los clientes intercambien un token externo por un token de acceso federado que autentica a una principal del grupo de cargas de trabajo. El principal del grupo de identidades para cargas de trabajo se identifica con un identificador principal similar al siguiente:

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

Los tokens de acceso federado son opacos y no se pueden introspeccionar. Los tokens no se pueden revocar y siguen siendo válidos hasta su vencimiento. Los vencimientos de cada tipo de token se establecen de la siguiente manera:

• La federación de identidades de personal establece el vencimiento del token en el menor de los siguientes dos valores:

  • Tiempo restante hasta que venza la sesión de la federación de identidades de personal

  • 1 hora

  El vencimiento de la sesión de federación de identidades de personal se determina según la hora de acceso y la duración de la sesión configurada para el grupo de federación de identidades de personal.

• La federación de Workload Identity establece el vencimiento del token para que coincida con el vencimiento del token externo.

Tokens de límite de acceso a las credenciales

Los tokens de límite de acceso a las credenciales autentican a un usuario o una cuenta de servicio y incluyen un límite de acceso. El límite de acceso restringe el token para que solo se pueda usar para acceder a un subconjunto definido de recursos de Cloud Storage.

A veces, los tokens de límite de acceso a las credenciales se denominan de alcance reducido porque se derivan de un token de entrada, pero son más restrictivos en los recursos a los que otorgan acceso.

El vencimiento de los tokens de límite de acceso a credenciales se deriva del vencimiento del token de entrada, que un token de acceso de cuenta de servicio. Los tokens de límite de acceso a credenciales son opacos y no se pueden introspeccionar ni revocar.

Tokens de límites de acceso a las credenciales emitidos por el cliente

Los tokens de límite de acceso a las credenciales emitidos por el cliente son similares a los tokens de límite de acceso a las credenciales, pero están optimizados para situaciones en las que los clientes necesitan obtener tokens de límite de acceso a las credenciales con diferentes límites de acceso con alta frecuencia.

Los clientes pueden crear tokens de límite de acceso de credenciales emitidas por el cliente de forma local con las bibliotecas cliente de Cloud y un token intermediario de límite de acceso, que deben actualizar periódicamente.

Los tokens de límite de acceso a credenciales emitidos por el cliente son opacos y no se pueden introspeccionar ni revocar.

Tokens de otorgamiento de tokens

Los tokens de concesión de tokens permiten que los clientes obtengan tokens nuevos o diferentes, posiblemente en un momento posterior. Cloud de Confiance by S3NS admite varios tipos diferentes de tokens de concesión de tokens, y todos tienen lo siguiente en común:

• Representan una autenticación previa.

• Autentican a una principal, que puede ser una identidad de Google (un usuario o una carga de trabajo) o una identidad externa.

• Se pueden canjear por un token de acceso.

• No se pueden usar para realizar llamadas a las APIs de Google, lo que las distingue de los tokens de acceso.

Los tokens de concesión de tokens pueden diferir de las siguientes maneras:

• Emisor: Es la parte que emite el token.

• Principal: Es el tipo de identidad principal que puede autenticar el token.

• Restricciones: Son las restricciones que se pueden imponer en el token.

En la siguiente tabla, se enumeran los diferentes tipos de tokens de concesión de tokens.

Los diferentes tipos de tokens de concesión también exhiben diferentes propiedades de seguridad:

• Formato: Algunos tokens son opacos. El cliente puede decodificar otros tokens.

• Duración: Los tokens difieren en su duración y en el grado en que se pueden modificar.

• Uso múltiple: Algunos tokens de concesión solo se pueden usar una vez. Otros tokens se pueden usar varias veces.

• Revocabilidad: Algunos tokens se pueden revocar. Los demás tokens seguirán siendo válidos hasta su vencimiento.

En la siguiente tabla, se resumen las diferencias entre estas propiedades para los tokens de concesión de tokens:

Tokens de actualización federados

Los tokens de actualización federados son tokens opacos que permiten a los clientes obtener tokens de acceso para un principal del grupo de identidades de personal, si el usuario autorizó previamente a un cliente a actuar en su nombre.

Al igual que los tokens de actualización, los tokens de actualización federados están vinculados a un cliente específico y solo se pueden usar en combinación con credenciales de cliente válidas, por ejemplo, un ID de cliente y un secreto del cliente.

A diferencia de los tokens de actualización, los tokens de actualización federados no se pueden revocar. La vida útil de un token de actualización federado está vinculada a la sesión de identidad de personal que se usó para obtener el token y sigue siendo válido hasta que vence la sesión.

Códigos de autorización federados

Al igual que los códigos de autorización, los códigos de autorización federados son tokens opacos de corta duración. Los códigos solo se deben usar durante la autenticación del usuario como intermediarios entre el cliente y el servidor de autorización de Cloud de Confiance by S3NS IAM.

Los códigos de autorización están vinculados a un cliente, solo se pueden usar en combinación con credenciales de cliente válidas y solo se pueden usar una vez.

Tokens web JSON externos

Los tokens web JSON (JWT) externos son emitidos por un proveedor de identidad externo, como Microsoft Entra ID, Okta, Kubernetes o GitHub. Pueden diferir en su estructura y contenido.

Si configuras la federación de Workforce Identity o la federación de Workload Identity, puedes establecer una relación de confianza entre Cloud de Confiance by S3NS y un proveedor de identidad externo. Luego, las cargas de trabajo pueden usar los JWT externos como tokens de concesión de tokens para obtener tokens de acceso federado.

Cuando usas la federación de identidades de personal, el token de acceso federado resultante autentica un principal del grupo de identidades de personal.

Cuando usas la federación de identidades para cargas de trabajo, el token de acceso federado resultante autentica a un principal del grupo de identidades para cargas de trabajo.

En ambos casos, el identificador principal se deriva de uno o más reclamos del JWT externo.

Para que sean compatibles con la federación de identidades del personal o la federación de identidades para cargas de trabajo, los JWT externos deben satisfacer requisitos específicos.

Aserciones o respuestas de SAML externas

Las confirmaciones externas del lenguaje de marcado de confirmación de seguridad (SAML) son confirmaciones de SAML 2.0 que emite un proveedor de identidad externo, como Microsoft Entra ID, Okta o Active Directory Federation Services. Estas aserciones de SAML externas se pueden incluir de forma opcional en una respuesta de SAML 2.0 o encriptarse.

Al igual que con los tokens web JSON externos, puedes configurar la federación de identidades de personal o la federación de identidades para cargas de trabajo de modo que las cargas de trabajo puedan usar aserciones o respuestas de SAML externas como tokens de concesión de tokens para obtener tokens de acceso federados.

Para ser compatibles con la federación de identidades para cargas de trabajo o la federación de identidades del personal de trabajo, las aserciones de SAML externas deben satisfacer requisitos específicos.

Token de Amazon Web Services (AWS) GetCallerIdentity

Los tokens externos de AWS GetCallerIdentity son BLOB de texto que contienen una solicitud firmada a la API de GetCallerIdentity de AWS. De manera similar a los tokens web de JSON externos, puedes configurar la federación de identidades del personal de trabajo o la federación de identidades para cargas de trabajo de modo que las cargas de trabajo puedan usar estos objetos binarios grandes de texto como un token de concesión de tokens para obtener tokens de acceso federados.

Tokens de identidad

Los tokens de ID permiten que los clientes identifiquen al usuario con el que interactúan. Cloud de Confiance by S3NS admite varios tipos diferentes de tokens de ID, y todos tienen lo siguiente en común:

• Tienen el formato de tokens web JSON (JWT) para que el cliente pueda decodificarlos, verificarlos e interpretarlos.

• Autentican una principal, que puede ser un usuario o una carga de trabajo.

• Se emiten para un cliente en particular.

• Son de corta duración y vencen después de una hora como máximo.

• No se pueden revocar.

• No se pueden usar para realizar llamadas a las APIs de Google, lo que las distingue de los tokens de acceso.

• No se pueden usar para obtener tokens de acceso, lo que los distingue de los tokens de concesión de tokens.

• Se pueden usar para autenticar llamadas entre microservicios o para autenticarse de forma programática en Identity-Aware Proxy (IAP).

Los tokens de identidad pueden diferir de las siguientes maneras:

• Público: Es la parte que debe decodificar y consumir el token.

• Emisor: Es la parte que emite el token.

• Duración: Los tokens difieren en su duración y en el grado en que se pueden modificar.

• Principal: Es el tipo de identidad principal que puede autenticar el token.

En la siguiente tabla, se enumeran los diferentes tipos de tokens de identidad.

Tokens de ID de cuentas de servicio

Los tokens de ID de cuentas de servicio son tokens web JSON (JWT) que autentican una cuenta de servicio.

A diferencia de los JWT de cuentas de servicio y las aserciones de JWT de cuentas de servicio, los tokens de ID de cuentas de servicio no están firmados por una clave de cuenta de servicio. En cambio, los tokens de ID de la cuenta de servicio están firmados por el conjunto de claves web JSON (JWKS) de Google.

Un token de ID de cuenta de servicio decodificado se ve similar al siguiente, con SIGNATURE reemplazado por la firma del 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

Un token de ID de cuenta de servicio incluye los siguientes campos:

El conjunto exacto de reclamaciones incluidas en un token de ID depende de la forma en que se solicita el token de ID. Por ejemplo, los tokens de ID solicitados por el servidor de metadatos de Compute Engine pueden incluir de forma opcional reclamos adicionales que afirman la identidad de la VM. Los tokens de ID solicitados con la API de IAM Credentials pueden incluir, de manera opcional, el ID de la organización del proyecto de la cuenta de servicio.

Los tokens de ID de la cuenta de servicio son válidos durante una hora y no se pueden revocar.

Aserciones de Identity-Aware Proxy

Las aserciones de Identity-Aware Proxy (IAP) son tokens web JSON (JWT) que IAP pasa a las aplicaciones web protegidas por IAP en el encabezado de la solicitud HTTP x-goog-iap-jwt-assertion. Las aserciones de IAP autentican a un usuario y también sirven como prueba de que IAP autorizó una solicitud.

• Cuentas de usuario administradas

• Cuentas personales

• Cuentas de servicio

• Principales del grupo de identidades del personal

Una aserción de IAP decodificada es similar a la siguiente, con SIGNATURE reemplazado por la firma del 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

Una aserción de IAP incluye los siguientes campos:

Para obtener más detalles sobre las declaraciones de la aserción de IAP, consulta Cómo verificar la carga útil del JWT.

Las confirmaciones de IAP son válidas durante 10 minutos y no se pueden revocar.