Tokens de autenticación
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Token del portador (JWT: RFC 7516) emitido por el socio de identidad (IdP) para certificar la identidad de un usuario.
Representación JSON |
{
"aud": string,
"email": string,
"exp": string,
"iat": string,
"iss": string,
"google_email": string,
...
}
|
Campos |
aud |
string
Es el público, según lo identifica el IdP. Se debe verificar con la configuración local.
|
email |
string (UTF-8)
La dirección de correo electrónico del usuario.
|
exp |
string
Es la hora de vencimiento.
|
iat |
string
Es la fecha y hora de emisión.
|
iss |
string
El emisor del token. Se debe validar con el conjunto de emisores de autenticación de confianza.
|
google_email |
string
Es un reclamo opcional que se usa cuando el reclamo de correo electrónico en este JWT es diferente del ID de correo electrónico de Google Workspace del usuario. Este reclamo contiene la identidad de correo electrónico de Google Workspace del usuario.
|
... |
Tu Servicio de Lista de Control de Acceso a Claves (KACLS) es libre de usar cualquier otro reclamo (ubicación, reclamo personalizado, etc.) para evaluar el perímetro.
|
Token de autenticación de KACLS para delegate
El token de autenticación contiene un token web JSON (JWT) (JWT: RFC 7516) que es un token de autenticación del portador.
A veces, un usuario no puede autenticarse directamente en un cliente.
En estos casos, el usuario puede delegar su acceso a un recurso específico a ese cliente. Esto se logra emitiendo un nuevo token de autenticación delegado que limita el alcance del token de autenticación original.
El token de autenticación delegado es similar al token de autenticación normal, pero con un reclamo adicional:
reclamar |
delegated_to |
string
Es un identificador de la entidad a la que se delegará la autenticación.
|
En un contexto de delegación, el reclamo resource_name
del token de autenticación se usa para identificar el objeto encriptado por la clave de encriptación de datos (DEK) para la que es válida la delegación.
El token se emite a través del servicio de lista de control de acceso a las claves (KACLS) con la llamada Delegate
. Pueden ser JWT autofirmados que el KACLS pueda validar, o bien el KACLS puede usar cualquier otro IdP para hacerlo, a través de una llamada de confianza.
Para que el token de autenticación delegado se considere válido, se debe proporcionar un token de autorización delegado para la misma operación. El token de autorización delegado es similar al token de autorización normal, pero contiene el reclamo adicional delegated_to
. Los valores de las reclamaciones delegated_to
y resource_name
deben coincidir con los valores del token de autenticación delegado.
Te recomendamos que establezcas un valor de tiempo de vida útil de 15 minutos para los tokens de autenticación delegada para evitar su posible reutilización en caso de filtración.
Representación JSON |
{
"email": string,
"iss": string,
"aud": string,
"exp": string,
"iat": string,
"google_email": string,
"delegated_to": string,
"resource_name": string
...
}
|
Campos |
email |
string (UTF-8)
Es la dirección de correo electrónico del usuario con formato UTF-8.
|
iss |
string
El emisor del token se debe validar con el conjunto de emisores de autenticación de confianza.
|
aud |
string
Es el público, según lo identifica el IdP. Se debe verificar con la configuración local.
|
exp |
string
Se debe verificar la hora de vencimiento.
|
iat |
string
Es la fecha y hora de emisión, que se debe verificar.
|
delegated_to |
string
Es un identificador de la entidad a la que se delegará la autenticación.
|
resource_name |
string
Es un identificador del objeto encriptado por la DEK para el que es válida la delegación.
|
... |
El KACLS es libre de usar cualquier otro reclamo (ubicación, reclamo personalizado, etc.) para evaluar el perímetro.
|
Token de autenticación de KACLS para PrivilegedUnwrap
Token del portador (JWT: RFC 7516) emitido por el socio de identidad (IdP) para certificar la identidad de un usuario.
Solo se usa en PrivilegedUnwrap
. Durante PrivilegedUnwrap
, si se usa un JWT de KACLS en lugar de un token de autenticación de IDP, el KACLS receptor primero debe recuperar el JWKS del emisor y, luego, verificar la firma del token antes de verificar las reclamaciones.
Representación JSON |
{
"aud": string,
"exp": string,
"iat": string,
"iss": string,
"kacls_url": string,
"resource_name": string
...
}
|
Campos |
aud |
string
Es el público, según lo identifica el IdP. Para las operaciones de encriptación del cliente (CSE) de Drive PrivilegedUnwrap , este valor debe ser kacls-migration .
|
exp |
string
Es la hora de vencimiento.
|
iat |
string
Es la fecha y hora de emisión.
|
iss |
string
El emisor del token. Se debe validar con el conjunto de emisores de autenticación de confianza. Debe coincidir con el KACLS_URL de los KACLS solicitantes. El conjunto de claves públicas del emisor se puede encontrar en /certs .
|
kacls_url |
string
Es la URL de los KACLS actuales en los que se desencriptan los datos.
|
resource_name |
string
Es un identificador del objeto encriptado por la DEK. Tamaño máximo: 128 bytes.
|
... |
Tu Servicio de Lista de Control de Acceso a Claves (KACLS) es libre de usar cualquier otro reclamo (ubicación, reclamo personalizado, etc.) para evaluar el perímetro.
|
Salvo que se indique lo contrario, el contenido de esta página está sujeto a la licencia Atribución 4.0 de Creative Commons, y los ejemplos de código están sujetos a la licencia Apache 2.0. Para obtener más información, consulta las políticas del sitio de Google Developers. Java es una marca registrada de Oracle o sus afiliados.
Última actualización: 2025-08-04 (UTC)
[null,null,["Última actualización: 2025-08-04 (UTC)"],[[["\u003cp\u003eKACLS uses bearer tokens (JWTs) issued by an identity provider (IdP) to verify user identity and authorize access.\u003c/p\u003e\n"],["\u003cp\u003eJWTs contain essential claims like audience, email, expiration, issuance, issuer, and potentially a Google Workspace email for specific scenarios.\u003c/p\u003e\n"],["\u003cp\u003eFor \u003ccode\u003ePrivilegedUnwrap\u003c/code\u003e operations, a KACLS JWT is used, requiring the recipient KACLS to verify the token signature and claims after fetching the issuer's JWKS.\u003c/p\u003e\n"],["\u003cp\u003eKACLS JWTs include specific claims like \u003ccode\u003ekacls_url\u003c/code\u003e and \u003ccode\u003eresource_name\u003c/code\u003e relevant to the decryption process.\u003c/p\u003e\n"],["\u003cp\u003eKACLS offers flexibility by allowing the use of additional claims for perimeter evaluation and custom authorization logic.\u003c/p\u003e\n"]]],["The document outlines two types of Bearer tokens (JWTs) used for user identity and KACLS authentication. User identity tokens, issued by the IdP, include fields like `aud`, `email`, `exp`, `iat`, `iss`, and `google_email` for email verification. KACLS authentication tokens, used during `PrivilegedUnwrap`, contain `aud` (specifically `kacls-migration`), `exp`, `iat`, `iss`, `kacls_url`, and `resource_name`. KACLS must verify the KACLS JWT's signature and claims after fetching the issuer's JWKS. Both types allow for custom claims.\n"],null,["# Authentication tokens\n\nBearer token ([JWT: RFC 7516](https://tools.ietf.org/html/rfc7516))\nissued by the identity partner (IdP) to attest a user's identity.\n\n| JSON representation ||\n|----------------------------------------------------------------------------------------------------------------------|---|\n| ``` { \"aud\": string, \"email\": string, \"exp\": string, \"iat\": string, \"iss\": string, \"google_email\": string, ... } ``` |\n\n| Fields ||\n|----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `aud` | `string` The audience, as identified by the IdP. Should be checked against the local configuration. |\n| `email` | `string (UTF-8)` The user's email address. |\n| `exp` | `string` Expiration time. |\n| `iat` | `string` Issuance time. |\n| `iss` | `string` The token issuer. Should be validated against the trusted set of authentication issuers. |\n| `google_email` | `string` An optional claim, to be used when the email claim in this JWT is different from the user's Google Workspace email ID. This claim carries the user's Google Workspace email identity. |\n| `...` | Your Key Access Control List Service (KACLS) is free to use any other claims (location, custom claim, etc) to evaluate the perimeter. |\n\nKACLS authentication token for `delegate`\n-----------------------------------------\n\nThe authentication token contains a JSON Web Token (JWT) ([JWT: RFC 7516](https://tools.ietf.org/html/rfc7516))\nthat is a bearer authentication token.\n\nSometimes a user is not able to authenticate on a client directly.\nIn these cases the user can delegate their access to a specific\nresource to that client. This is achieved through issuing a new\ndelegated authentication token that limits the scope of the original\nauthentication token.\n\nThe delegated authentication token is similar to the ordinary\nauthentication token with one additional claim:\n\n| claim ||\n|----------------|----------------------------------------------------------------------|\n| `delegated_to` | `string` An identifier for the entity to delegate authentication to. |\n\nThe `resource_name` claim in the authentication token is, in a\ndelegation context, used for identifying the object encrypted by the\nData Encryption Key (DEK) for which the delegation is valid.\n\nThe token is issued by the Key Access Control List Service (KACLS)\nusing the `Delegate` call. It may be either self-signed JWTs\nthat KACLS is able to validate, or KACLS may use any other IdP to do\nthat, through a trusted call.\n\nIn order for the delegated authentication token to be considered valid, a\ndelegated authorization token must be provided for the same operation. The\ndelegated authorization token is similar to the ordinary authorization token,\nbut contains the additional claim `delegated_to`. The values of the\n`delegated_to` and `resource_name` claims must match the values in the\ndelegated authentication token.\n\nWe recommend that you set a lifetime value of 15 minutes for the delegated\nauthentication tokens to avoid potential reuse in case of leakage.\n\n| JSON representation ||\n|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|---|\n| ``` { \"email\": string, \"iss\": string, \"aud\": string, \"exp\": string, \"iat\": string, \"google_email\": string, \"delegated_to\": string, \"resource_name\": string ... } ``` |\n\n| Fields ||\n|-----------------|-------------------------------------------------------------------------------------------------------|\n| `email` | `string (UTF-8)` The user's UTF-8 formatted email address. |\n| `iss` | `string` The token issuer, should be validated against the trusted set of authentication issuers. |\n| `aud` | `string` The audience, as identified by the IdP. Should be checked against the local configuration. |\n| `exp` | `string` Expiration time, should be checked. |\n| `iat` | `string` Issuance time, should be checked. |\n| `delegated_to` | `string` An identifier for the entity to delegate authentication to. |\n| `resource_name` | `string` An identifier for the object encrypted by the DEK, for which the delegation is valid. |\n| `...` | The KACLS is free to use any other claims (location, custom claim, etc...) to evaluate the perimeter. |\n\nKACLS authentication token for `PrivilegedUnwrap`\n-------------------------------------------------\n\nBearer token ([JWT: RFC 7516](https://tools.ietf.org/html/rfc7516))\nissued by the identity partner (IdP) to attest a user's identity.\n\nThis is only used on `PrivilegedUnwrap`. During `PrivilegedUnwrap`, if a KACLS\nJWT is used in place of an IDP authentication token, the recipient KACLS must\nfirst fetch the JWKS of the issuer, then verify the token signature, before\nchecking the claims.\n\n| JSON representation ||\n|--------------------------------------------------------------------------------------------------------------------------|---|\n| ``` { \"aud\": string, \"exp\": string, \"iat\": string, \"iss\": string, \"kacls_url\": string, \"resource_name\": string ... } ``` |\n\n| Fields ||\n|-----------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `aud` | `string` The audience, as identified by the IdP. For Drive client-side encryption (CSE) `PrivilegedUnwrap` operations, this should be `kacls-migration`. |\n| `exp` | `string` Expiration time. |\n| `iat` | `string` Issuance time. |\n| `iss` | `string` The token issuer. Should be validated against the trusted set of authentication issuers. Must match the `KACLS_URL` of the requesting KACLS. The public key set of the issuer can be found at /certs. |\n| `kacls_url` | `string` URL of current KACLS, that the data is being decrypted on. |\n| `resource_name` | `string` An identifier for the object encrypted by the DEK. Maximum size: 128 bytes. |\n| `...` | Your Key Access Control List Service (KACLS) is free to use any other claims (location, custom claim, etc) to evaluate the perimeter. |"]]