Tokeny uwierzytelniania
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Token okaziciela (JWT: RFC 7516) wydany przez partnera ds. tożsamości (IdP) w celu potwierdzenia tożsamości użytkownika.
| Zapis JSON |
{
"aud": string,
"email": string,
"exp": string,
"iat": string,
"iss": string,
"google_email": string,
...
}
|
| Pola |
aud |
string
Odbiorcy zidentyfikowani przez dostawcę tożsamości. Należy sprawdzić, czy jest zgodna z konfiguracją lokalną.
|
email |
string (UTF-8)
Adres e-mail użytkownika.
|
exp |
string
Czas wygaśnięcia.
|
iat |
string
Czas wydania.
|
iss |
string
Wystawca tokena. Powinny być weryfikowane na podstawie zaufanego zestawu wystawców uwierzytelniania.
|
google_email |
string
Opcjonalna deklaracja używana, gdy deklaracja dotycząca adresu e-mail w tym JWT różni się od identyfikatora e-mail użytkownika Google Workspace. To roszczenie zawiera tożsamość e-mail użytkownika Google Workspace.
|
... |
Usługa listy kontroli dostępu do kluczy może bezpłatnie używać innych roszczeń (lokalizacji, roszczenia niestandardowego itp.) do oceny perymetru.
|
Token uwierzytelniania KACLS dla delegate
Token uwierzytelniający zawiera token sieciowy JSON (JWT) (JWT: RFC 7516), który jest tokenem uwierzytelniającym typu bearer.
Czasami użytkownik nie może uwierzytelnić się bezpośrednio na urządzeniu klienta.
W takich przypadkach użytkownik może przekazać klientowi dostęp do określonego zasobu. Odbywa się to przez wydanie nowego tokena uwierzytelniania delegowanego, który ogranicza zakres oryginalnego tokena uwierzytelniania.
Delegowany token uwierzytelniania jest podobny do zwykłego tokena uwierzytelniania, ale zawiera jeszcze jedno dodatkowe roszczenie:
| twierdzenie : stwierdzenie |
delegated_to |
string
Identyfikator podmiotu, któremu ma zostać przekazane uwierzytelnianie.
|
Roszczenie resource_name w tokenie uwierzytelniania jest w kontekście delegowania używane do identyfikowania obiektu zaszyfrowanego za pomocą klucza szyfrującego dane (DEK), dla którego delegowanie jest ważne.
Token jest wydawany przez usługę listy kontroli dostępu do kluczy (KACLS) za pomocą wywołania Delegate. Mogą to być tokeny JWT z podpisem własnym, które KACLS może zweryfikować, lub KACLS może użyć dowolnego innego dostawcy tożsamości, aby to zrobić, za pomocą zaufanego wywołania.
Aby token uwierzytelniania delegowanego został uznany za prawidłowy, dla tej samej operacji musi zostać podany token autoryzacji delegowanej. Token autoryzacji delegowanej jest podobny do zwykłego tokena autoryzacji, ale zawiera dodatkowe roszczenie delegated_to. Wartości roszczeń delegated_to i resource_name muszą być zgodne z wartościami w tokenie uwierzytelniania delegowanego.
Aby uniknąć potencjalnego ponownego użycia w przypadku wycieku danych, zalecamy ustawienie czasu życia delegowanych tokenów uwierzytelniania na 15 minut.
| Zapis JSON |
{
"email": string,
"iss": string,
"aud": string,
"exp": string,
"iat": string,
"google_email": string,
"delegated_to": string,
"resource_name": string
...
}
|
| Pola |
email |
string (UTF-8)
Adres e-mail użytkownika w formacie UTF-8.
|
iss |
string
Wydawca tokena powinien być weryfikowany na podstawie zaufanego zestawu wydawców uwierzytelniania.
|
aud |
string
Odbiorcy zidentyfikowani przez dostawcę tożsamości. Należy sprawdzić, czy jest zgodna z konfiguracją lokalną.
|
exp |
string
Czas wygaśnięcia powinien być sprawdzony.
|
iat |
string
Czas wydania należy sprawdzić.
|
delegated_to |
string
Identyfikator podmiotu, któremu ma zostać przekazane uwierzytelnianie.
|
resource_name |
string
Identyfikator obiektu zaszyfrowanego za pomocą klucza DEK, dla którego delegowanie jest ważne.
|
... |
Usługa KACLS może używać dowolnych innych roszczeń (lokalizacji, roszczenia niestandardowego itp.) do oceny obszaru.
|
Token uwierzytelniania KACLS dla PrivilegedUnwrap
Token okaziciela (JWT: RFC 7516) wydany przez partnera ds. tożsamości (IdP) w celu potwierdzenia tożsamości użytkownika.
Jest on używany tylko w przypadku PrivilegedUnwrap. Podczas PrivilegedUnwrap, jeśli zamiast tokena uwierzytelniania dostawcy tożsamości używany jest token JWT KACLS, odbiorca KACLS musi najpierw pobrać zestaw kluczy JWK wystawcy, a następnie zweryfikować podpis tokena przed sprawdzeniem deklaracji.
| Zapis JSON |
{
"aud": string,
"exp": string,
"iat": string,
"iss": string,
"kacls_url": string,
"resource_name": string
...
}
|
| Pola |
aud |
string
Odbiorcy zidentyfikowani przez dostawcę tożsamości. W przypadku operacji szyfrowania po stronie klienta na Dysku Google PrivilegedUnwrap ta wartość powinna wynosić kacls-migration.
|
exp |
string
Czas wygaśnięcia.
|
iat |
string
Czas wydania.
|
iss |
string
Wystawca tokena. Powinny być weryfikowane na podstawie zaufanego zestawu wystawców uwierzytelniania. Musi być zgodny z wartością KACLS_URL żądającego KACLS. Zbiór kluczy publicznych wydawcy można znaleźć pod adresem /certs.
|
kacls_url |
string
Adres URL bieżącego KACLS, na którym dane są odszyfrowywane.
|
resource_name |
string
Identyfikator obiektu zaszyfrowany za pomocą klucza DEK. Maksymalny rozmiar: 128 bajtów.
|
... |
Usługa listy kontroli dostępu do kluczy może bezpłatnie używać innych roszczeń (lokalizacji, roszczenia niestandardowego itp.) do oceny perymetru.
|
O ile nie stwierdzono inaczej, treść tej strony jest objęta licencją Creative Commons – uznanie autorstwa 4.0, a fragmenty kodu są dostępne na licencji Apache 2.0. Szczegółowe informacje na ten temat zawierają zasady dotyczące witryny Google Developers. Java jest zastrzeżonym znakiem towarowym firmy Oracle i jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-08-04 UTC.
[null,null,["Ostatnia aktualizacja: 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. |"]]
