Tipos de tokens

Cloud de Confiance by S3NS emite varios tipos de tokens, que se diferencian por su finalidad y por las partes entre las que se intercambian.

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

Los tokens de acceso y de identidad son tokens de portador. Los tokens de portador son una clase general de tokens que conceden acceso a la parte que los posee.

Para usar tokens de portador en la autenticación, se necesita un protocolo cifrado, como HTTPS. Si se intercepta un token de portador, un agente pernicioso puede usarlo para obtener acceso.

Si los tokens de portador no proporcionan suficiente seguridad para tu caso práctico, puedes reducir el riesgo de robo de tokens mediante el acceso contextual, limitando la duración de los tokens de acceso o usando una solución de seguridad de la capa de transporte (TLS) mutua, como Chrome Enterprise Premium.

Tokens de acceso

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

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

• Se emiten para un cliente concreto.

• Son de corta duración y caducan al cabo de unas horas como máximo.

• Están restringidas a determinados permisos de OAuth, endpoints o recursos. Esto significa que, por lo general, un token de acceso no concede acceso a todos los recursos de un usuario, sino solo a un subconjunto de ellos.

Los tokens de acceso pueden diferir en los siguientes aspectos:

• Emisor: la parte que emite el token.

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

• Restricciones: las restricciones que se pueden imponer al token.

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

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

• Formato: algunos tokens de acceso son opacos, lo que significa que tienen un formato propietario y no se pueden inspeccionar. Otros tokens se codifican como JSON Web Token, que el cliente puede decodificar.

• Tiempo de vida: los tokens se diferencian en el tiempo de vida y en el grado en que se pueden modificar.

• Revocabilidad: algunos tokens se pueden revocar. Los demás tokens siguen siendo válidos hasta que caduquen.

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

Tokens de acceso de cuentas de servicio

Los tokens de acceso de cuentas 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 las cuentas de servicio no se pueden revocar y siguen siendo válidos hasta que caducan.

De forma predeterminada, los tokens de acceso de la cuenta de servicio caducan al cabo de una hora. Con el método serviceAccounts.generateAccessToken, puedes solicitar tokens con diferentes tiempos de vida. Como los tiempos de vida de los tokens más largos 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 tiempos de vida superiores a una hora.

JSON Web Tokens de cuentas de servicio

Los JSON Web Tokens (JWTs) de las cuentas de servicio autentican una cuenta de servicio. Mientras que un servidor de autorización emite tokens de acceso de cuenta de servicio, el cliente puede emitir JWTs de cuenta de servicio.

A veces se denominan JWTs "autofirmados". Pueden ser útiles cuando necesites autenticarte en algunas APIs de Google sin obtener un token de acceso del servidor de autorización, por ejemplo, al crear tus propias bibliotecas de 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 ámbito de OAuth o un endpoint de API, y un tiempo de vencimiento.

2. Firma la carga útil con una clave de cuenta de servicio de la cuenta de servicio correspondiente. Los clientes pueden firmar la carga útil sin conexión mediante una clave de cuenta de servicio gestionada por el usuario o con conexión mediante el método signJwt y una clave de cuenta de servicio gestionada por Google. Para obtener más información, consulta Crear un JSON Web Token autofirmado.

Un JWT de cuenta de servicio decodificado tiene un aspecto similar al siguiente, con SIGNATURE sustituido 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 ámbito de OAuth en la clave scope, un JWT de cuenta de servicio puede especificar un endpoint 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 durante un máximo de una hora y no se pueden revocar.

Tokens de acceso federados

Los tokens de acceso federados autentican una identidad principal de grupo de Workforce o una identidad principal de grupo de cargas de trabajo.

Workforce Identity Federation permite a los clientes intercambiar un token externo por un token de acceso federado que autentica a una entidad de un grupo de trabajo. El principal del grupo de identidades de Workforce se identifica mediante un identificador principal similar al siguiente:

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

La federación de identidades de cargas de trabajo permite a los clientes intercambiar un token externo por un token de acceso federado que autentica a una entidad de un grupo de cargas de trabajo. El principal del grupo de identidades de carga de trabajo se identifica mediante un identificador principal similar al siguiente:

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

Los tokens de acceso federados son opacos y no se pueden introspeccionar. Los tokens no se pueden revocar y siguen siendo válidos hasta que caduquen. Los vencimientos de cada tipo de token se definen de la siguiente manera:

• La federación de identidades de Workforce define la caducidad del token como el menor de los dos valores siguientes:

  • Tiempo restante hasta que caduque la sesión de Workforce Identity Federation

  • 1 hora

  La caducidad de la sesión de Workforce Identity Federation se determina en función de la hora de inicio de sesión y de la duración de la sesión configurada para el grupo de Workforce Identity Federation.

• La federación de identidades de cargas de trabajo define la caducidad del token para que coincida con la del token externo.

Tokens de límite de acceso a credenciales

Los tokens de límite de acceso de 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 credenciales se denominan de ámbito reducido porque se derivan de un token de entrada, pero tienen más restricciones en cuanto a los recursos a los que conceden acceso.

La caducidad de los tokens de límite de acceso de las credenciales se deriva de la caducidad del token de entrada, que un token de acceso de cuenta de servicio. Los tokens de límite de acceso a las credenciales son opacos y no se pueden inspeccionar ni revocar.

Tokens de límite de acceso de credenciales emitidos por el cliente

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

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

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

Tokens de concesión de tokens

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

• Representan una autenticación anterior.

• Autentican una entidad 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 hacer llamadas a las APIs de Google, lo que las diferencia de los tokens de acceso.

Los tokens de concesión de tokens pueden diferir en los siguientes aspectos:

• Emisor: la parte que emite el token.

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

• Restricciones: las restricciones que se pueden imponer al 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 de tokens también tienen diferentes propiedades de seguridad:

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

• Tiempo de vida: los tokens tienen un tiempo de vida diferente y se pueden modificar en mayor o menor medida.

• Multiuso: algunos tokens de concesión de tokens solo se pueden usar una vez. Otros tokens se pueden usar varias veces.

• Revocabilidad: algunos tokens se pueden revocar. Los demás tokens siguen siendo válidos hasta que caduquen.

En la siguiente tabla se resumen las diferencias entre estas propiedades para los tokens que conceden 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 de un grupo de identidades de la fuerza de trabajo si el usuario ha autorizado previamente a un cliente para que actúe 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, como un ID de cliente y un secreto de cliente.

A diferencia de los tokens de actualización, los tokens de actualización federados no se pueden revocar. El tiempo de vida de un token de actualización federado está vinculado a la sesión de identidad de los empleados que se usó para obtener el token y sigue siendo válido hasta que caduca 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 de usuarios como intermediarios entre el cliente y el Cloud de Confiance by S3NS servidor de autorización de IAM.

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

Tokens web JSON externos

Los tokens web JSON (JWTs) externos los emite un proveedor de identidades externo, como Microsoft Entra ID, Okta, Kubernetes o GitHub. Pueden diferir en su estructura y contenido.

Si configuras Workforce Identity Federation o Workload Identity Federation, puedes establecer una relación de confianza entre Cloud de Confiance by S3NS y un proveedor de identidades externo. Las cargas de trabajo pueden usar JWTs externos como tokens de concesión de tokens para obtener tokens de acceso federados.

Cuando usas Workforce Identity Federation, el token de acceso federado resultante autentica a un principal del grupo de identidades de Workforce.

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

En ambos casos, el identificador de la entidad principal se deriva de una o varias reclamaciones del JWT externo.

Para que sean compatibles con la federación de identidades de trabajo o de cargas de trabajo, los JWTs externos deben cumplir requisitos específicos.

Aserciones o respuestas SAML externas

Las aserciones lenguaje de marcado para confirmaciones de seguridad (SAML) externas son aserciones SAML 2.0 emitidas por un proveedor de identidades externo, como Microsoft Entra ID, Okta o Servicios de federación de Active Directory. Estas aserciones SAML externas se pueden incluir de forma opcional en una respuesta SAML 2.0 o cifrarse.

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

Para que sean compatibles con la federación de identidades de Workforce o de cargas de trabajo, las aserciones SAML externas deben cumplir requisitos específicos.

Token de GetCallerIdentityAmazon Web Services (AWS)

Los tokens externos de AWS GetCallerIdentity son blobs de texto que contienen una solicitud firmada a la API de GetCallerIdentityAWS. Al igual que con los tokens web JSON externos, puedes configurar la federación de identidades de Workforce o la federación de identidades de cargas de trabajo para que las cargas de trabajo puedan usar estos blobs de texto como token de concesión de tokens para obtener tokens de acceso federados.

Tokens de identidad

Los tokens de ID permiten a los clientes identificar al usuario con el que están interactuando. Cloud de Confiance by S3NS admite varios tipos de tokens de ID, y todos tienen lo siguiente en común:

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

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

• Se emiten para un cliente concreto.

• Son de corta duración y caducan al cabo de una hora como máximo.

• No se pueden revocar.

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

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

• Se pueden usar para autenticar llamadas entre microservicios o para autenticarse mediante programación en Identity-Aware Proxy (IAP).

Los tokens de identidad pueden diferir en los siguientes aspectos:

• Audiencia: la parte que debe decodificar y consumir el token.

• Emisor: la parte que emite el token.

• Tiempo de vida: los tokens tienen un tiempo de vida diferente y se pueden modificar en mayor o menor medida.

• Principal: 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 cuenta de servicio

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

A diferencia de los JWTs 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 su lugar, los tokens de ID de la cuenta de servicio están firmados por el conjunto de claves web de JSON (JWKS) de Google.

Un token de ID de cuenta de servicio decodificado tiene un aspecto similar al siguiente, con SIGNATURE sustituido 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 solicite el token de ID. Por ejemplo, los tokens de ID solicitados por el servidor de metadatos de Compute Engine pueden incluir de forma opcional reclamaciones adicionales que afirmen la identidad de la VM. Los tokens de ID solicitados mediante la API IAM Credentials pueden incluir opcionalmente el ID de organización del proyecto de la cuenta de servicio.

Los tokens de ID de 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 (JWTs) que IAP transfiere a las aplicaciones web protegidas por IAP en el encabezado de solicitud HTTP x-goog-iap-jwt-assertion. Las aserciones de IAP autentican a un usuario y también sirven como prueba de que IAP ha autorizado una solicitud.

• Cuentas de usuario gestionadas

• Cuentas de consumidor

• Cuentas de servicio

• Principales de grupos de identidades de Workforce

Una aserción de IAP decodificada tiene un aspecto similar al siguiente, donde SIGNATURE se sustituye 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 compra en la aplicación incluye los siguientes campos:

Para obtener más información sobre las reclamaciones de aserción de IAP, consulta Verificar la carga útil de JWT.

Las aserciones de compras en aplicaciones son válidas durante 10 minutos y no se pueden revocar.