Tokens de autenticación

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.