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 |
Il pubblico, come identificato dall'IdP. Deve essere controllato in base alla configurazione locale. |
email |
L'indirizzo email dell'utente. |
exp |
Ora di scadenza. |
iat |
Ora di emissione. |
iss |
L'emittente del token. Deve essere convalidato in base all'insieme attendibile di emittenti di autenticazione. |
google_email |
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 |
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 |
L'indirizzo email dell'utente in formato UTF-8. |
iss |
L'emittente del token deve essere convalidato rispetto all'insieme attendibile di emittenti di autenticazione. |
aud |
Il pubblico, come identificato dall'IdP. Deve essere controllato in base alla configurazione locale. |
exp |
Ora di scadenza, deve essere selezionata. |
iat |
L'ora di emissione deve essere controllata. |
delegated_to |
Un identificatore per l'entità a cui delegare l'autenticazione. |
resource_name |
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 |
Il pubblico, come identificato dall'IdP. Per le operazioni di crittografia lato client di Drive |
exp |
Ora di scadenza. |
iat |
Ora di emissione. |
iss |
L'emittente del token. Deve essere convalidato in base all'insieme attendibile di emittenti di autenticazione. Deve corrispondere a |
kacls_url |
URL degli ACL KACLS attuali su cui vengono decriptati i dati. |
resource_name |
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. |