認証トークン

ユーザーの ID を証明するために ID パートナー（IdP）によって発行される署名なしトークン（JWT: RFC 7516）。

JSON 表現 
{
  "aud": string,
  "email": string,
  "exp": string,
  "iat": string,
  "iss": string,
  "google_email": string,
  ...
}
フィールド
aud

string

IdP によって識別されたオーディエンス。ローカル構成に対して確認する必要があります。
email

string (UTF-8)

ユーザーのメール アドレスです。
exp

string

有効期限。
iat

string

発行時間。
iss

string

トークン発行者。信頼できる認証発行者のセットに対して検証する必要があります。
google_email

string

この JWT のメール クレームがユーザーの Google Workspace メール ID と異なる場合に使用する省略可能なクレーム。このクレームには、ユーザーの Google Workspace メール ID が含まれます。
...

鍵アクセス制御リスト サービス（KACLS）は、他のクレーム（位置情報、カスタム クレームなど）を使用して境界を評価できます。

delegate の KACLS 認証トークン

認証トークンには、署名なし認証トークンである JSON ウェブトークン（JWT）（JWT: RFC 7516）が含まれています。

クライアントでユーザーを直接認証できない場合があります。このような場合、ユーザーは特定のリソースへのアクセス権をそのクライアントに委任できます。これは、元の認証トークンのスコープを制限する新しい委任認証トークンを発行することで実現されます。

委任された認証トークンは、通常の認証トークンと似ていますが、次の 1 つの追加クレームがあります。

申し立て
delegated_to

string

認証を委任するエンティティの識別子。

認証トークンの resource_name クレームは、委任コンテキストで、委任が有効なデータ暗号鍵（DEK）によって暗号化されたオブジェクトの識別に使用されます。

このトークンは、Delegate 呼び出しを使用して鍵アクセス制御リスト サービス（KACLS）によって発行されます。KACLS が検証できる自己署名 JWT である場合もあれば、KACLS が信頼できる呼び出しを通じて他の IdP を使用して検証する場合もあります。

委任された認証トークンが有効と見なされるには、同じオペレーションに対して委任された認可トークンが提供されている必要があります。委任された認証トークンは通常の認証トークンと似ていますが、追加のクレーム delegated_to が含まれています。delegated_to クレームと resource_name クレームの値は、委任された認証トークンの値と一致する必要があります。

漏洩した場合の再利用を防ぐため、委任された認証トークンの有効期間を 15 分に設定することをおすすめします。

JSON 表現 
{
  "email": string,
  "iss": string,
  "aud": string,
  "exp": string,
  "iat": string,
  "google_email": string,
  "delegated_to": string,
  "resource_name": string
  ...
}
フィールド
email

string (UTF-8)

ユーザーの UTF-8 形式のメールアドレス。
iss

string

トークン発行者は、信頼できる認証発行者のセットに対して検証する必要があります。
aud

string

IdP によって識別されたオーディエンス。ローカル構成に対して確認する必要があります。
exp

string

有効期限を確認する必要があります。
iat

string

発行時間を確認する必要があります。
delegated_to

string

認証を委任するエンティティの識別子。
resource_name

string

委任が有効な DEK で暗号化されたオブジェクトの識別子。
...

KACLS は、他のクレーム（ロケーション、カスタム クレームなど）を使用して境界を評価できます。

PrivilegedUnwrap の KACLS 認証トークン

ユーザーの ID を証明するために ID パートナー（IdP）によって発行される署名なしトークン（JWT: RFC 7516）。

これは PrivilegedUnwrap でのみ使用されます。PrivilegedUnwrap の間に、IDP 認証トークンの代わりに KACLS JWT が使用される場合、受信側の KACLS は、まず発行者の JWKS を取得し、トークン署名を検証してから、クレームを確認する必要があります。

JSON 表現 
{
  "aud": string,
  "exp": string,
  "iat": string,
  "iss": string,
  "kacls_url": string,
  "resource_name": string
  ...
}
フィールド
aud

string

IdP によって識別されたオーディエンス。ドライブのクライアントサイド暗号化（CSE）の PrivilegedUnwrap オペレーションの場合、これは kacls-migration にする必要があります。
exp

string

有効期限。
iat

string

発行時間。
iss

string

トークン発行者。信頼できる認証発行者のセットに対して検証する必要があります。リクエスト元の KACLS の KACLS_URL と一致している必要があります。発行者の公開鍵セットは /certs で確認できます。
kacls_url

string

データが復号化されている現在の KACLS の URL。
resource_name

string

DEK で暗号化されたオブジェクトの識別子。最大サイズ: 128 バイト。
...

鍵アクセス制御リスト サービス（KACLS）は、他のクレーム（位置情報、カスタム クレームなど）を使用して境界を評価できます。