Authentifizierungs-Tokens

Inhabertoken (JWT: RFC 7519), das von dem Identitätsanbieter (IdP) ausgestellt wurde, 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 vom IdP identifiziert. Sollte mit der lokalen Konfiguration verglichen werden.

email

string (UTF-8)

Die E-Mail-Adresse des Nutzers.

exp

string

Ablaufzeit.

iat

string

Ausstellungszeit.

iss

string

Der Tokenaussteller. Sollte mit der vertrauenswürdigen Gruppe von Authentifizierungsausstellern verglichen werden.

google_email

string

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

...

Ihr Key Access Control List Service (KACLS) kann alle anderen Ansprüche (Standort, benutzerdefinierter Anspruch usw.) verwenden, um den Perimeter zu bewerten.

KACLS-Authentifizierungstoken für delegate

Das Authentifizierungstoken enthält ein JSON Web Token (JWT) (JWT: RFC 7519), das ein Inhaber-Authentifizierungstoken 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 geschieht durch die Ausstellung eines neuen delegierten Authentifizierungstokens, das den Umfang des ursprünglichen Authentifizierungstokens einschränkt.

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

Anspruch
delegated_to

string

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

Der Anspruch resource_name im Authentifizierungstoken wird im Rahmen der Delegierung verwendet, um das Objekt zu identifizieren, das mit dem Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) verschlüsselt wurde und für das die Delegierung gilt.

Das Token wird vom Key Access Control List Service (KACLS) mit dem Aufruf Delegate ausgestellt. Dabei kann es sich entweder um selbstsignierte JWTs handeln, die vom KACLS validiert werden können, oder der KACLS kann über einen vertrauenswürdigen Aufruf einen anderen IdP verwenden.

Damit das delegierte Authentifizierungstoken als gültig betrachtet wird, muss für denselben Vorgang ein delegiertes Autorisierungstoken bereitgestellt werden. Das delegierte Autorisierungstoken ähnelt dem normalen Autorisierungstoken, enthält aber den zusätzlichen Anspruch delegated_to. Die Werte der Ansprüche 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 Datenlecks 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 E-Mail-Adresse des Nutzers im UTF-8-Format.

iss

string

Der Tokenaussteller. Sollte mit der vertrauenswürdigen Gruppe von Authentifizierungsausstellern verglichen werden.

aud

string

Die Zielgruppe, wie vom IdP identifiziert. Sollte mit der lokalen Konfiguration verglichen werden.

exp

string

Ablaufzeit. Sollte geprüft werden.

iat

string

Ausstellungszeit. Sollte geprü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 Delegierung gilt.

...

Der KACLS kann alle anderen Ansprüche (Standort, benutzerdefinierter Anspruch, usw.) verwenden, um den Perimeter zu bewerten.

KACLS-Authentifizierungstoken für PrivilegedUnwrap

Inhabertoken (JWT: RFC 7519), das vom Identitätsanbieter (IdP) ausgestellt wurde, um die Identität eines Nutzers zu bestätigen.

Dieses Token wird nur für PrivilegedUnwrap verwendet. Wenn während PrivilegedUnwrap ein KACLS-JWT anstelle eines IdP-Authentifizierungstokens verwendet wird, muss der empfangende KACLS zuerst die JWKS des Ausstellers abrufen, dann die Tokensignatur überprüfen und erst dann die Ansprüche prüfen.

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

string

Die Zielgruppe, wie vom IdP identifiziert. Für Vorgänge der clientseitigen Verschlüsselung von Google Drive PrivilegedUnwrap sollte dieser Wert kacls-migration sein.

exp

string

Ablaufzeit.

iat

string

Ausstellungszeit.

iss

string

Der Tokenaussteller. Sollte mit der vertrauenswürdigen Gruppe von Authentifizierungsausstellern verglichen werden. Muss mit der KACLS_URL des anfragenden KACLS übereinstimmen. Die Menge der öffentlichen Schlüssel des Ausstellers finden Sie unter <iss>/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 alle anderen Ansprüche (Standort, benutzerdefinierter Anspruch usw.) verwenden, um den Perimeter zu bewerten.