Jetons d'authentification
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Jeton de support (JWT : RFC 7516) émis par le partenaire d'identité (IdP) pour attester de l'identité d'un utilisateur.
| Représentation JSON |
{
"aud": string,
"email": string,
"exp": string,
"iat": string,
"iss": string,
"google_email": string,
...
}
|
| Champs |
aud |
string
Audience, telle qu'identifiée par le fournisseur d'identité. Doit être vérifié par rapport à la configuration locale.
|
email |
string (UTF-8)
Adresse e-mail de l'utilisateur.
|
exp |
string
Date d'expiration.
|
iat |
string
Heure d'émission.
|
iss |
string
Émetteur de jeton. Doit être validé par rapport à l'ensemble approuvé d'émetteurs d'authentification.
|
google_email |
string
Revendication facultative à utiliser lorsque la revendication d'adresse e-mail dans ce JWT est différente de l'adresse e-mail Google Workspace de l'utilisateur. Cette revendication contient l'identité de l'adresse e-mail Google Workspace de l'utilisateur.
|
... |
Votre service de liste de contrôle d'accès aux clés (KACLS) est libre d'utiliser d'autres revendications (emplacement, revendication personnalisée, etc.) pour évaluer le périmètre.
|
Jeton d'authentification KACLS pour delegate
Le jeton d'authentification contient un jeton Web JSON (JWT) (JWT : RFC 7516) qui est un jeton d'authentification de support.
Parfois, un utilisateur n'est pas en mesure de s'authentifier directement sur un client.
Dans ce cas, l'utilisateur peut déléguer son accès à une ressource spécifique à ce client. Pour ce faire, un nouveau jeton d'authentification délégué est émis, ce qui limite le champ d'application du jeton d'authentification d'origine.
Le jeton d'authentification déléguée est semblable au jeton d'authentification ordinaire, mais comporte une revendication supplémentaire :
| revendication |
delegated_to |
string
Identifiant de l'entité à laquelle déléguer l'authentification.
|
Dans un contexte de délégation, la revendication resource_name du jeton d'authentification est utilisée pour identifier l'objet chiffré par la clé de chiffrement des données (DEK) pour laquelle la délégation est valide.
Le jeton est émis par le service de liste de contrôle d'accès aux clés (KACLS) à l'aide de l'appel Delegate. Il peut s'agir de jetons JWT autosignés que KACLS est en mesure de valider, ou KACLS peut utiliser n'importe quel autre IdP pour ce faire, via un appel de confiance.
Pour que le jeton d'authentification déléguée soit considéré comme valide, un jeton d'autorisation déléguée doit être fourni pour la même opération. Le jeton d'autorisation déléguée est semblable au jeton d'autorisation ordinaire, mais contient la revendication supplémentaire delegated_to. Les valeurs des revendications delegated_to et resource_name doivent correspondre à celles du jeton d'authentification déléguée.
Nous vous recommandons de définir une durée de vie de 15 minutes pour les jetons d'authentification déléguée afin d'éviter toute réutilisation potentielle en cas de fuite.
| Représentation JSON |
{
"email": string,
"iss": string,
"aud": string,
"exp": string,
"iat": string,
"google_email": string,
"delegated_to": string,
"resource_name": string
...
}
|
| Champs |
email |
string (UTF-8)
Adresse e-mail de l'utilisateur au format UTF-8.
|
iss |
string
L'émetteur du jeton doit être validé par rapport à l'ensemble approuvé d'émetteurs d'authentification.
|
aud |
string
Audience, telle qu'identifiée par le fournisseur d'identité. Doit être vérifié par rapport à la configuration locale.
|
exp |
string
Le délai d'expiration doit être vérifié.
|
iat |
string
L'heure d'émission doit être vérifiée.
|
delegated_to |
string
Identifiant de l'entité à laquelle déléguer l'authentification.
|
resource_name |
string
Identifiant de l'objet chiffré par la clé DEK pour lequel la délégation est valide.
|
... |
Le KACLS est libre d'utiliser toute autre revendication (lieu, revendication personnalisée, etc.) pour évaluer le périmètre.
|
Jeton d'authentification KACLS pour PrivilegedUnwrap
Jeton de support (JWT : RFC 7516) émis par le partenaire d'identité (IdP) pour attester de l'identité d'un utilisateur.
Cette option n'est disponible que sur PrivilegedUnwrap. Lors de l'PrivilegedUnwrap, si un jeton JWT KACLS est utilisé à la place d'un jeton d'authentification IdP, le KACLS destinataire doit d'abord récupérer le JWKS de l'émetteur, puis vérifier la signature du jeton, avant de vérifier les revendications.
| Représentation JSON |
{
"aud": string,
"exp": string,
"iat": string,
"iss": string,
"kacls_url": string,
"resource_name": string
...
}
|
| Champs |
aud |
string
Audience, telle qu'identifiée par le fournisseur d'identité. Pour les opérations de chiffrement côté client (CSE) Drive PrivilegedUnwrap, cette valeur doit être kacls-migration.
|
exp |
string
Date d'expiration.
|
iat |
string
Heure d'émission.
|
iss |
string
Émetteur de jeton. Doit être validé par rapport à l'ensemble approuvé d'émetteurs d'authentification. Doit correspondre au KACLS_URL du KACLS demandeur. L'ensemble de clés publiques de l'émetteur est disponible sur /certs.
|
kacls_url |
string
URL du KACLS actuel sur lequel les données sont déchiffrées.
|
resource_name |
string
Identifiant de l'objet chiffré par la clé de chiffrement des données. Taille maximale : 128 octets.
|
... |
Votre service de liste de contrôle d'accès aux clés (KACLS) est libre d'utiliser d'autres revendications (emplacement, revendication personnalisée, etc.) pour évaluer le périmètre.
|
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/04 (UTC).
[null,null,["Dernière mise à jour le 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. |"]]
