Authentifizierungs-Tokens

Inhabertoken (JWT: RFC 7516), das vom Identitätspartner (IdP) ausgestellt wird, um die Identität eines Nutzers zu bestätigen.

JSON-Darstellung 
{
  "aud": string,
  "email": string,
  "exp": string,
  "iat": string,
  "iss": string,
  "google_email": string,
  ...
}
Felder
aud

string

Die Zielgruppe, wie sie vom IdP identifiziert wird. Sollte mit der lokalen Konfiguration abgeglichen werden.
email

string (UTF-8)

Die E-Mail-Adresse des Nutzers.
exp

string

Ablaufzeit.
iat

string

Ausstellungszeit.
iss

string

Der Tokenaussteller. Sollte anhand der vertrauenswürdigen Gruppe von Authentifizierungsstellenausstellern validiert werden.
google_email

string

Eine optionale Anforderung, die verwendet werden soll, wenn sich die E-Mail-Anforderung in diesem JWT von der Google Workspace-E-Mail-ID des Nutzers unterscheidet. Dieser Anspruch enthält die Google Workspace-E-Mail-Identität des Nutzers.
...

Ihr Key Access Control List Service (KACLS) kann beliebige andere Behauptungen (Standort, benutzerdefinierte Behauptung usw.) verwenden, um den Perimeter zu bewerten.

KACLS-Authentifizierungstoken für delegate

Das Authentifizierungstoken enthält ein JSON-Web-Token (JWT) (JWT: RFC 7516), das ein Inhaberauthentifizierungstoken ist.

Manchmal kann sich ein Nutzer nicht direkt auf einem Client authentifizieren. In diesen Fällen kann der Nutzer den Zugriff auf eine bestimmte Ressource an diesen Client delegieren. Dies wird durch die Ausstellung eines neuen delegierten Authentifizierungstokens erreicht, das den Umfang des ursprünglichen Authentifizierungstokens einschränkt.

Das delegierte Authentifizierungstoken ähnelt dem normalen Authentifizierungstoken, enthält jedoch einen zusätzlichen Anspruch:

Behauptung
delegated_to

string

Eine Kennung für die Entität, an die die Authentifizierung delegiert werden soll.

Der resource_name-Anspruch im Authentifizierungstoken wird im Delegierungskontext verwendet, um das Objekt zu identifizieren, das mit dem Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) verschlüsselt wurde, für den die Delegierung gültig ist.

Das Token wird vom Key Access Control List Service (KACLS) mit dem Delegate-Aufruf ausgestellt. Dabei kann es sich entweder um selbstsignierte JWTs handeln, die KACLS validieren kann, oder KACLS kann dazu über einen vertrauenswürdigen Aufruf einen beliebigen anderen IdP verwenden.

Damit das delegierte Authentifizierungstoken als gültig betrachtet wird, muss für denselben Vorgang ein delegiertes Autorisierungstoken angegeben werden. Das delegierte Autorisierungstoken ähnelt dem normalen Autorisierungstoken, enthält aber die zusätzliche Anforderung delegated_to. Die Werte der Anforderungen delegated_to und resource_name müssen mit den Werten im delegierten Authentifizierungstoken übereinstimmen.

Wir empfehlen, für die delegierten Authentifizierungstokens eine Lebensdauer von 15 Minuten festzulegen, um eine mögliche Wiederverwendung im Falle eines Lecks zu vermeiden.

JSON-Darstellung 
{
  "email": string,
  "iss": string,
  "aud": string,
  "exp": string,
  "iat": string,
  "google_email": string,
  "delegated_to": string,
  "resource_name": string
  ...
}
Felder
email

string (UTF-8)

Die UTF‑8-formatierte E‑Mail-Adresse des Nutzers.
iss

string

Der Tokenaussteller muss anhand der vertrauenswürdigen Authentifizierungsaussteller validiert werden.
aud

string

Die Zielgruppe, wie sie vom IdP identifiziert wird. Sollte mit der lokalen Konfiguration abgeglichen werden.
exp

string

Die Ablaufzeit sollte überprüft werden.
iat

string

Die Ausstellungszeit sollte überprüft werden.
delegated_to

string

Eine Kennung für die Entität, an die die Authentifizierung delegiert werden soll.
resource_name

string

Eine Kennung für das Objekt, das mit dem DEK verschlüsselt wurde und für das die Delegation gültig ist.
...

Das KACLS kann kostenlos andere Behauptungen (Standort, benutzerdefinierte Behauptung usw.) verwenden, um den Perimeter zu bewerten.

KACLS-Authentifizierungstoken für PrivilegedUnwrap

Inhabertoken (JWT: RFC 7516), das vom Identitätspartner (IdP) ausgestellt wird, um die Identität eines Nutzers zu bestätigen.

Diese Option wird nur auf PrivilegedUnwrap verwendet. Während PrivilegedUnwrap muss der KACLS-Empfänger, wenn ein KACLS-JWT anstelle eines IDP-Authentifizierungstokens verwendet wird, zuerst die JWKS des Ausstellers abrufen und dann die Tokensignatur überprüfen, bevor die Ansprüche geprüft werden.

JSON-Darstellung 
{
  "aud": string,
  "exp": string,
  "iat": string,
  "iss": string,
  "kacls_url": string,
  "resource_name": string
  ...
}
Felder
aud

string

Die Zielgruppe, wie sie vom IdP identifiziert wird. Für PrivilegedUnwrap-Vorgänge der clientseitigen Verschlüsselung von Drive (CSE) sollte dies kacls-migration sein.
exp

string

Ablaufzeit.
iat

string

Ausstellungszeit.
iss

string

Der Tokenaussteller. Sollte anhand der vertrauenswürdigen Gruppe von Authentifizierungsstellenausstellern validiert werden. Muss mit dem KACLS_URL des anfragenden KACLS übereinstimmen. Die öffentlichen Schlüssel des Ausstellers finden Sie unter /certs.
kacls_url

string

URL des aktuellen KACLS, auf dem die Daten entschlüsselt werden.
resource_name

string

Eine Kennung für das Objekt, das mit dem DEK verschlüsselt wurde. Maximale Größe: 128 Byte.
...

Ihr Key Access Control List Service (KACLS) kann beliebige andere Behauptungen (Standort, benutzerdefinierte Behauptung usw.) verwenden, um den Perimeter zu bewerten.