Token di autenticazione
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Token di tipo Bearer (JWT: RFC 7516)
emesso dal partner di identità (IdP) per attestare l'identità di un utente.
| Rappresentazione JSON |
{
"aud": string,
"email": string,
"exp": string,
"iat": string,
"iss": string,
"google_email": string,
...
}
|
| Campi |
aud |
string
Il pubblico, come identificato dall'IdP. Deve essere controllato in base alla configurazione locale.
|
email |
string (UTF-8)
L'indirizzo email dell'utente.
|
exp |
string
Ora di scadenza.
|
iat |
string
Ora di emissione.
|
iss |
string
L'emittente del token. Deve essere convalidato in base all'insieme attendibile di emittenti di autenticazione.
|
google_email |
string
Un'attestazione facoltativa da utilizzare quando l'attestazione email in questo JWT è diversa dall'ID email Google Workspace dell'utente. Questa rivendicazione
contiene l'identità email Google Workspace dell'utente.
|
... |
Il tuo servizio di elenco di controllo dell'accesso per le chiavi (KACLS) è libero di utilizzare qualsiasi altra rivendicazione (posizione, rivendicazione personalizzata e così via) per valutare il perimetro.
|
Token di autenticazione KACLS per delegate
Il token di autenticazione contiene un token JWT (JSON Web Token) (JWT: RFC 7516)
che è un token di autenticazione bearer.
A volte un utente non è in grado di autenticarsi direttamente su un client.
In questi casi, l'utente può delegare l'accesso a una risorsa specifica al cliente. Ciò si ottiene emettendo un nuovo
token di autenticazione delegata che limita l'ambito del token di autenticazione
originale.
Il token di autenticazione delegata è simile al token di autenticazione
ordinario con un'ulteriore rivendicazione:
| dichiarazione |
delegated_to |
string
Un identificatore per l'entità a cui delegare l'autenticazione.
|
L'attestazione resource_name nel token di autenticazione viene utilizzata, in un contesto di delega, per identificare l'oggetto criptato dalla chiave di crittografia dei dati (DEK) per cui la delega è valida.
Il token viene emesso dal servizio di elenco di controllo dell'accesso per le chiavi (KACLS)
utilizzando la chiamata Delegate. Possono essere JWT autofirmati
che KACLS è in grado di convalidare oppure KACLS può utilizzare qualsiasi altro IdP per farlo
tramite una chiamata attendibile.
Affinché il token di autenticazione delegata sia considerato valido, deve essere fornito un token di autorizzazione delegata per la stessa operazione. Il
token di autorizzazione delegata è simile al normale token di autorizzazione,
ma contiene l'attestazione aggiuntiva delegated_to. I valori delle rivendicazioni
delegated_to e resource_name devono corrispondere ai valori del
token di autenticazione delegata.
Ti consigliamo di impostare un valore di durata di 15 minuti per i token di autenticazione delegata per evitare un potenziale riutilizzo in caso di perdita.
| Rappresentazione JSON |
{
"email": string,
"iss": string,
"aud": string,
"exp": string,
"iat": string,
"google_email": string,
"delegated_to": string,
"resource_name": string
...
}
|
| Campi |
email |
string (UTF-8)
L'indirizzo email dell'utente in formato UTF-8.
|
iss |
string
L'emittente del token deve essere convalidato rispetto all'insieme attendibile di emittenti di autenticazione.
|
aud |
string
Il pubblico, come identificato dall'IdP. Deve essere controllato in base alla configurazione locale.
|
exp |
string
Ora di scadenza, deve essere selezionata.
|
iat |
string
L'ora di emissione deve essere controllata.
|
delegated_to |
string
Un identificatore per l'entità a cui delegare l'autenticazione.
|
resource_name |
string
Un identificatore dell'oggetto criptato dalla DEK per cui la delega è valida.
|
... |
KACLS è libero di utilizzare qualsiasi altra rivendicazione (posizione, rivendicazione personalizzata e così via) per valutare il perimetro.
|
Token di autenticazione KACLS per PrivilegedUnwrap
Token di tipo Bearer (JWT: RFC 7516)
emesso dal partner di identità (IdP) per attestare l'identità di un utente.
Viene utilizzato solo su PrivilegedUnwrap. Durante PrivilegedUnwrap, se viene utilizzato un JWT KACLS al posto di un token di autenticazione IdP, il KACLS destinatario deve prima recuperare il JWKS dell'emittente, quindi verificare la firma del token, prima di controllare le rivendicazioni.
| Rappresentazione JSON |
{
"aud": string,
"exp": string,
"iat": string,
"iss": string,
"kacls_url": string,
"resource_name": string
...
}
|
| Campi |
aud |
string
Il pubblico, come identificato dall'IdP. Per le operazioni di crittografia lato client di Drive PrivilegedUnwrap,
questo valore deve essere kacls-migration.
|
exp |
string
Ora di scadenza.
|
iat |
string
Ora di emissione.
|
iss |
string
L'emittente del token. Deve essere convalidato in base all'insieme attendibile di emittenti di autenticazione. Deve corrispondere a KACLS_URL del KACLS richiedente. Il set di chiavi pubbliche dell'emittente è disponibile all'indirizzo /certs.
|
kacls_url |
string
URL degli ACL KACLS attuali su cui vengono decriptati i dati.
|
resource_name |
string
Un identificatore dell'oggetto criptato dalla DEK. Dimensione massima: 128 byte.
|
... |
Il tuo servizio di elenco di controllo dell'accesso per le chiavi (KACLS) è libero di utilizzare qualsiasi altra rivendicazione (posizione, rivendicazione personalizzata e così via) per valutare il perimetro.
|
Salvo quando diversamente specificato, i contenuti di questa pagina sono concessi in base alla licenza Creative Commons Attribution 4.0, mentre gli esempi di codice sono concessi in base alla licenza Apache 2.0. Per ulteriori dettagli, consulta le norme del sito di Google Developers. Java è un marchio registrato di Oracle e/o delle sue consociate.
Ultimo aggiornamento 2025-08-04 UTC.
[null,null,["Ultimo aggiornamento 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. |"]]
