認可と構成証明による Secure Data Connect

Firebase Data Connect は、次のような堅牢なクライアントサイド セキュリティを提供します。

  • モバイル クライアントとウェブ クライアントの認可
  • 個々のクエリレベルとミューテーション レベルの認可制御
  • Firebase App Check によるアプリ構成証明。

Data Connect は、次の機能でこのセキュリティを拡張します。

  • サーバーサイド認可
  • IAM を使用した Firebase プロジェクトと Cloud SQL ユーザーのセキュリティ。

クライアントのクエリとミューテーションを承認する

Data ConnectFirebase Authentication と完全に統合されているため、データにアクセスするユーザーに関する豊富なデータ(認証)を設計で使用して、そのユーザーがアクセスできるデータ(認可)を制御できます。

Data Connect には、クエリとミューテーション用の @auth ディレクティブがあり、オペレーションの認可に必要な認証レベルを設定できます。このガイドでは、@auth ディレクティブとその例について説明します

さらに、Data Connect はミューテーションに埋め込まれたクエリの実行をサポートしているため、データベースに保存した追加の認可条件を取得し、@check ディレクティブでこれらの条件を使用して、囲むミューテーションが承認されているかどうかを判断できます。この認可ケースでは、@redact ディレクティブを使用して、ワイヤー プロトコルでクライアントにクエリ結果を返すかどうか、および生成された SDK で埋め込みクエリを省略するかどうかを制御できます。これらのディレクティブの概要と例をご覧ください。

@auth ディレクティブについて

@auth ディレクティブをパラメータ化して、一般的なアクセス シナリオの多くに対応するいくつかのプリセット アクセスレベルのいずれかに従うようにできます。これらのレベルは、PUBLIC(いかなる種類の認証も行わずにすべてのクライアントからのクエリとミューテーションを許可)から NO_ACCESSFirebase Admin SDK を使用する特権サーバー環境以外でクエリとミューテーションを禁止)までです。これらのレベルはそれぞれ、Firebase Authentication が提供する認証フローと関連付けられています。

レベル 定義
PUBLIC このオペレーションは、認証の有無にかかわらず誰でも実行できます。
PUBLIC このオペレーションは、認証の有無にかかわらず誰でも実行できます。
USER_ANON Firebase Authentication で匿名でログインしたユーザーを含む、識別されたすべてのユーザーは、クエリまたはミューテーションを実行する権限があります。
USER Firebase Authentication でログインしたすべてのユーザーは、匿名ログイン ユーザーを除き、クエリまたはミューテーションを実行する権限があります。
USER_EMAIL_VERIFIED 確認済みのメールアドレスを使用して Firebase Authentication でログインしたユーザーは、クエリまたはミューテーションを実行する権限が付与されます。
NO_ACCESS このオペレーションは、Admin SDK のコンテキスト外で実行することはできません。

これらの事前設定されたアクセスレベルを起点として、where フィルタとサーバー上で評価される Common Expression Language(CEL)式を使用して、@auth ディレクティブで複雑で堅牢な認可チェックを定義できます。

@auth ディレクティブを使用して一般的な認可シナリオを実装する

事前設定されたアクセスレベルは、認可の出発点です。

USER アクセスレベルは、最初に使用できる最も一般的な基本レベルです。

完全に安全なアクセスは、USER レベルと、ユーザー属性、リソース属性、ロールなどのチェックを行うフィルタと式に基づいて構築されます。USER_ANON レベルと USER_EMAIL_VERIFIED レベルは、USER ケースのバリエーションです。

式の構文を使用すると、オペレーションで渡された認証データを表す auth オブジェクトを使用してデータを評価できます。これは、認証トークンの標準データとトークンのカスタムデータの両方です。auth オブジェクトで使用可能なフィールドの一覧については、リファレンス セクションをご覧ください。

もちろん、最初から PUBLIC が適切なアクセスレベルであるユースケースもあります。繰り返しになりますが、アクセスレベルは常に出発点であり、堅牢なセキュリティを確保するには追加のフィルタと式が必要です。

このガイドでは、USERPUBLIC でビルドする方法の例を示します。

モチベーションを高める例

次のベスト プラクティスの例は、特定のコンテンツが支払いプランでロックされているブログ プラットフォームの次のスキーマを参照しています。

このようなプラットフォームでは、UsersPosts をモデル化している可能性があります。

type User @table(key: "uid") {
  uid: String!
  name: String
  birthday: Date
  createdAt: Timestamp! @default(expr: "request.time")
}

type Post @table {
  author: User!
  text: String!
  # "one of 'draft', 'public', or 'pro'"
  visibility: String! @default(value: "draft")
  # "the time at which the post should be considered published. defaults to
  # immediately"
  publishedAt: Timestamp! @default(expr: "request.time")
  createdAt: Timestamp! @default(expr: "request.time")
  updatedAt: Timestamp! @default(expr: "request.time")
}

ユーザー所有のリソース

Firebase では、リソースのユーザー所有権(次のケースでは Posts の所有権)をテストするフィルタと式を記述することをおすすめします。

次の例では、認証トークンのデータが読み取られ、式を使用して比較されます。一般的なパターンは、where: {authorUid: {eq_expr: "auth.uid"}} などの式を使用して、保存されている authorUid を認証トークンで渡された auth.uid(ユーザー ID)と比較することです。

作成

この認可方法では、認証トークンの auth.uidauthorUid フィールドとして各新しい Post に追加し、後続の認可テストで比較できるようにします。

# Create a new post as the current user
mutation CreatePost($text: String!, $visibility: String) @auth(level: USER) {
  post_insert(data: {
    # set the author's uid to the current user uid
    authorUid_expr: "auth.uid"
    text: $text
    visibility: $visibility
  })
}
更新

クライアントが Post の更新を試みると、渡された auth.uid を保存されている authorUid と照合してテストできます。

# Update one of the current user's posts
mutation UpdatePost($id: UUID!, $text: String, $visibility: String) @auth(level:USER) {
  post_update(
    # only update posts whose author is the current user
    first: { where: {
      id: {eq: $id}
      authorUid: {eq_expr: "auth.uid"}
    }}
    data: {
      text: $text
      visibility: $visibility
      # insert the current server time for updatedAt
      updatedAt_expr: "request.time"
    }
  )
}
削除

削除オペレーションの承認にも同じ手法が使用されます。

# Delete one of the current user's posts
mutation DeletePost($id: UUID!) @auth(level: USER) {
  post_delete(
    # only delete posts whose author is the current user
    first: { where: {
      id: {eq: $id}
      authorUid: {eq_expr: "auth.uid"}
    }}
  )
}
# Common display information for a post
fragment DisplayPost on Post {
  id, text, createdAt, updatedAt
  author { uid, name }
}
リスト
# List all posts belonging to the current user
query ListMyPosts @auth(level: USER) {
  posts(where: {
    userUid: {eq_expr: "auth.uid"}
  }) {
    # See the fragment above
    ...DisplayPost
    # also show visibility since it is user-controlled
    visibility
  }
}
Get
# Get a post only if it belongs to the current user
query GetMyPost($id: UUID!) @auth(level: USER) {
  post(key: {id: $id},
    first: {where: {
      id: {eq: $id}
      authorUid: {eq_expr: "auth.uid"}}
      }}, {
      # See the fragment above
      ...DisplayPost
      # also show visibility since it is user-controlled
      visibility
  }
}

データをフィルタリングする

Data Connect の認可システムでは、PUBLIC などの事前設定されたアクセスレベルと組み合わせて高度なフィルタを作成したり、認証トークンのデータを使用したりできます。

認可システムでは、次の例に示すように、ベースアクセスレベルなしで式のみを使用することもできます。

リソース属性でフィルタする

ここでは、ベースのセキュリティ レベルが PUBLIC に設定されているため、認可は認証トークンに基づいていません。ただし、データベース内のレコードを一般公開に適したものとして明示的に設定できます。データベースに Post レコードがあり、visibility が「public」に設定されているとします。

# List all posts marked as 'public' visibility
query ListPublicPosts @auth(level: PUBLIC) {
  posts(where: {
    # Test that visibility is "public"
    visibility: {eq: "public"}
    # Only display articles that are already published
    publishedAt: {lt_expr: "request.time"}
  }) {
    # see the fragment above
    ...DisplayPost
  }
}
ユーザーの認証情報でフィルタする

ここでは、認証トークンを渡してアプリの「プロ」プランのユーザーを識別するカスタム ユーザー クレームを設定し、認証トークンの auth.token.plan フィールドにフラグを付けたとします。式はこのフィールドに対してテストできます。

# List all public or pro posts, only permitted if user has "pro" plan claim
query ProListPosts @auth(expr: "auth.token.plan == 'pro'") {
  posts(where: {
    # display both public posts and "pro" posts
    visibility: {in: ['public', 'pro']},
    # only display articles that are already published
    publishedAt: {lt_expr: "request.time"},
  }) {
    # see the fragment above
    ...DisplayPost
    # show visibility so pro users can see which posts are pro\
    visibility
  }
}
順序と上限でフィルタする

また、Post レコードに visibility を設定して、「プロ」ユーザーが利用できるコンテンツであることを識別し、データのプレビューまたはティーザー リスティングでは、返されるレコードの数をさらに制限することもできます。

# Show 2 oldest Pro post as a preview
query ProTeaser @auth(level: USER) {
  posts(
    where: {
      # show only pro posts
      visibility: {eq: "pro"}
      # that have already been published more than 30 days ago
      publishedAt: {lt_time: {now: true, sub: {days: 30}}}
    },
    # order by publish time
    orderBy: [{publishedAt: DESC}],
    # only return two posts
    limit: 2
  ) {
    # See the fragment above
    ...DisplayPost
  }
}
ロール別にフィルタ

カスタム クレームで admin ロールが定義されている場合は、それに応じてオペレーションをテストして承認できます。

# List all posts unconditionally iff the current user has an admin claim
query AdminListPosts @auth(expr: "auth.token.admin == true") {
  posts { ...DisplayPost }
}

@check ディレクティブと @redact ディレクティブを理解する

@check ディレクティブは、指定したフィールドがクエリ結果に存在することを確認します。フィールド値をテストするには、Common Expression Language(CEL)式を使用します。ディレクティブのデフォルトの動作は、null 値のノードをチェックして拒否することです。

@redact ディレクティブは、クライアントからのレスポンスの一部を削除します。除去されたフィールドは、副作用(データの変更や @check など)について引き続き評価され、その結果は CEL 式の後続のステップで引き続き使用できます。

Data Connect では、@check ディレクティブと @redact ディレクティブは、承認チェックのコンテキストで最もよく使用されます。承認データの検索に関する説明をご覧ください。

@check ディレクティブと @redact ディレクティブを追加して認可データを検索する

一般的な認可のユースケースでは、カスタム認可ロールをデータベース(特別な権限テーブルなど)に保存し、それらのロールを使用して、データの作成、更新、削除のミューテーションを承認します。

認可データのルックアップを使用すると、ユーザー ID に基づいてロールをクエリし、CEL 式を使用してミューテーションが承認されているかどうかを判断できます。たとえば、承認済みクライアントが映画のタイトルを更新できるように UpdateMovieTitle ミューテーションを記述できます。

以降では、映画レビュー アプリのデータベースに認可ロールが MoviePermission テーブルに保存されていることを前提とします。

# MoviePermission
# Suppose a user has an authorization role with respect to records in the Movie table
type MoviePermission @table(key: ["doc", "userId"]) {
  movie: Movie! # implies another field: movieId: UUID!
  userId: String! # Can also be a reference to a User table, doesn't matter
  role: String!
}

次の実装例では、UpdateMovieTitle ミューテーションに、MoviePermission からデータを取得する query フィールドと、オペレーションが安全で堅牢であることを確認するための次のディレクティブが含まれています。

  • すべての認可クエリとチェックがアトミックに完了または失敗するようにする @transaction ディレクティブ。
  • @redact ディレクティブ: レスポンスからクエリ結果を省略します。つまり、Data Connect サーバーで認可チェックが行われますが、機密データはクライアントに公開されません。
  • クエリ結果に対する認可ロジックを評価する一対の @check ディレクティブ。たとえば、特定のユーザー ID に変更を加える適切なロールがあるかどうかをテストします。

mutation UpdateMovieTitle($movieId: UUID!, $newTitle: String!) @auth(level: USER) @transaction {
  # Step 1: Query and check
  query @redact {
    moviePermission( # Look up a join table called MoviePermission with a compound key.
      key: {movieId: $movieId, userId_expr: "auth.uid"}
    # Step 1a: Use @check to test if the user has any role associated with the movie
    # Here the `this` binding refers the lookup result, i.e. a MoviePermission object or null
    # The `this != null` expression could be omitted since rejecting on null is default behavior
    ) @check(expr: "this != null", message: "You do not have access to this movie") {
      # Step 1b: Check if the user has the editor role for the movie
      # Next we execute another @check; now `this` refers to the contents of the `role` field
      role @check(expr: "this == 'editor'", message: "You must be an editor of this movie to update title")
    }
  }
  # Step 2: Act
  movie_update(id: $movieId, data: {
    title: $newTitle
  })
}

認可で避けるべきアンチパターン

前のセクションでは、@auth ディレクティブを使用する際のパターンについて説明しました。

また、避けるべき重要なアンチパターンにも注意する必要があります。

クエリとミューテーションの引数にユーザー属性 ID と認証トークン パラメータを渡さない

Firebase Authentication は、認証フローを表示し、登録済みユーザー ID や認証トークンに保存されている多数のフィールドなどの認証データを安全にキャプチャするための強力なツールです。

クエリとミューテーションの引数でユーザー ID と認証トークン データを渡すことはおすすめしません。

# Antipattern!
# This incorrectly allows any user to view any other user's posts
query AllMyPosts($userId: String!) @auth(level: USER) {
  posts(where: {authorUid: {eq: $userId}}) {
    id, text, createdAt
  }
}

フィルタなしで USER アクセスレベルを使用しないでください

このガイドで何度か説明したように、USERUSER_ANONUSER_EMAIL_VERIFIED などのコア アクセスレベルは、フィルタと式で拡張される認可チェックのベースラインと開始点です。リクエストを実行しているユーザーをチェックする対応するフィルタまたは式なしでこれらのレベルを使用することは、基本的に PUBLIC レベルを使用する場合と同じです。

# Antipattern!
# This incorrectly allows any user to view all documents
query ListDocuments @auth(level: USER) {
  documents {
    id
    title
    text
  }
}

プロトタイピングに PUBLIC または USER アクセスレベルを使用しないでください

開発をスピードアップするために、すべてのオペレーションを PUBLIC アクセスレベルまたは USER アクセスレベルに設定し、すべてのオペレーションを承認してコードをすばやくテストできるように、さらに強化せずに済ませたくなるかもしれません。

この方法で初期のプロトタイプを作成したら、NO_ACCESS から PUBLIC レベルと USER レベルの本番環境対応の認可に切り替えます。ただし、このガイドに示すように追加のロジックを追加せずに、PUBLIC または USER としてデプロイしないでください。

# Antipattern!
# This incorrectly allows anyone to delete any post
mutation DeletePost($id: UUID!) @auth(level: PUBLIC) {
  post: post_delete(
    id: $id,
  )
}

アプリ構成証明に Firebase App Check を使用する

認証と認可は、Data Connect セキュリティの重要な要素です。認証と認可をアプリ構成証明と組み合わせることで、非常に堅牢なセキュリティ ソリューションを実現できます。

Firebase App Check による構成証明を使用すると、アプリを実行しているデバイスは、アプリまたはデバイスの構成証明プロバイダを使用して、Data Connect オペレーションが正規のアプリから発信され、リクエストが改ざんされていない正規のデバイスから発信されていることを証明します。この証明書は、アプリが Data Connect に送信するすべてのリクエストに添付されます。

Data ConnectApp Check を有効にして、そのクライアント SDK をアプリに含める方法については、App Check の概要をご覧ください。

@auth(level) ディレクティブの認証レベル

次の表に、すべての標準アクセスレベルとその CEL の同等を示します。認証レベルは、広いレベルから狭いレベルの順に表示されます。各レベルは、次のレベルに一致するすべてのユーザーを対象としています。

レベル 定義
PUBLIC このオペレーションは、認証の有無にかかわらず誰でも実行できます。

考慮事項: データはどのユーザーでも読み取ったり変更したりできます。 Firebase では、商品やメディアのリスティングなど、一般公開されているデータにはこのレベルの認可をおすすめします。ベスト プラクティスの事例と代替手段をご覧ください。

@auth(expr: "true") と同等

@auth フィルタと式は、このアクセスレベルと組み合わせて使用できません。このような式は、400 エラーで失敗します。
USER_ANON Firebase Authentication で匿名でログインしたユーザーを含む、識別されたすべてのユーザーは、クエリまたはミューテーションを実行する権限があります。

注: USER_ANONUSER のサブセットです。

考慮事項: このレベルの認可では、クエリとミューテーションを慎重に設計する必要があります。このレベルでは、Authentication を使用してユーザーが匿名でログインできます(自動ログインはユーザーのデバイスにのみ関連付けられます)。データがユーザーに属しているかどうかなどの他のチェックは、このレベルでは行われません。ベスト プラクティスの事例と代替手段をご覧ください。

Authentication 匿名ログイン フローは uid を発行するため、USER_ANON レベルは
と同等です。 @auth(expr: "auth.uid != nil")
USER Firebase Authentication でログインしたすべてのユーザーは、匿名ログイン ユーザーを除き、クエリまたはミューテーションを実行する権限があります。

考慮事項: このレベルの認可では、クエリとミューテーションを慎重に設計する必要があります。このレベルでは、ユーザーが Authentication でログインしていることのみがチェックされ、データがユーザーに属しているかどうかなどの他のチェックは行われません。ベスト プラクティスの事例と代替手段をご覧ください。

@auth(expr: "auth.uid != nil && auth.token.firebase.sign_in_provider != 'anonymous'")" と同等
USER_EMAIL_VERIFIED 確認済みのメールアドレスを使用して Firebase Authentication でログインしたユーザーは、クエリまたはミューテーションを実行する権限が付与されます。

考慮事項: メール確認は Authentication を使用して行われるため、より堅牢な Authentication メソッドに基づいています。そのため、このレベルでは USERUSER_ANON と比較してセキュリティが強化されます。このレベルでは、ユーザーが確認済みのメールアドレスで Authentication にログインしていることのみがチェックされ、データがユーザーに属しているかどうかなどの他のチェックは行われません。ベスト プラクティスの事例と代替手段をご覧ください。

@auth(expr: "auth.uid != nil && auth.token.email_verified")" と同等
NO_ACCESS このオペレーションは、Admin SDK のコンテキスト外で実行することはできません。

@auth(expr: "false") と同等

@auth(expr)@check(expr) の CEL リファレンス

このガイドの他の例に示すように、Common Expression Language(CEL)で定義された式を使用して、@auth(expr:) ディレクティブと @check ディレクティブで Data Connect の承認を制御できます。

このセクションでは、これらのディレクティブの式の作成に関連する CEL 構文について説明します。

CEL の完全なリファレンス情報については、CEL 仕様をご覧ください。

クエリとミューテーションで渡される変数をテストする

@auth(expr) 構文を使用すると、クエリとミューテーションから変数にアクセスしてテストできます。

たとえば、vars.status を使用して、$status などのオペレーション変数を含めることができます。

mutation Update($id: UUID!, $status: Any) @auth(expr: "has(vars.status)")

式で使用できるデータ

@auth(expr:)@check(expr:) の両方の CEL 式は、次の式を評価できます。

  • request.operationName
  • varsrequest.variables の別名)
  • authrequest.auth の別名)

また、@check(expr:) 式では次の値を評価できます。

  • this(現在のフィールドの値)

request.operationName オブジェクト

request.operarationName オブジェクトには、オペレーションのタイプ(クエリまたはミューテーション)が格納されます。

vars オブジェクト

vars オブジェクトを使用すると、式でクエリまたはミューテーションで渡されたすべての変数にアクセスできます。

式で vars.<variablename> を使用して、完全修飾 request.variables.<variablename> のエイリアスとして使用できます。

# The following are equivalent
mutation StringType($v: String!) @auth(expr: "vars.v == 'hello'")
mutation StringType($v: String!) @auth(expr: "request.variables.v == 'hello'")

auth オブジェクト

Authentication は、データへのアクセスをリクエストしているユーザーを識別し、その情報を式で構築できるオブジェクトとして提供します。

フィルタと式では、request.auth のエイリアスとして auth を使用できます。

auth オブジェクトには次の情報が含まれます。

  • uid: リクエストしているユーザーに割り当てられた一意のユーザー ID。
  • token: Authentication によって収集された値のマップ。

auth.token の内容について詳しくは、認証トークン内のデータをご覧ください。

this バインディング

バインディング this は、@check ディレクティブが適用されているフィールドに評価されます。基本的なケースでは、単一値のクエリ結果を評価できます。

mutation UpdateMovieTitle($movieId: UUID!, $newTitle: String!) @auth(level: USER) @transaction {
  # Step 1: Query and check
  query @redact {
    moviePermission( # Look up a join table called MoviePermission with a compound key.
      key: {movieId: $movieId, userId_expr: "auth.uid"}
    ) {
      # Check if the user has the editor role for the movie. `this` is the string value of `role`.
      # If the parent moviePermission is null, the @check will also fail automatically.
      role @check(expr: "this == 'editor'", message: "You must be an editor of this movie to update title")
    }
  }
  # Step 2: Act
  movie_update(id: $movieId, data: {
    title: $newTitle
  })
}

祖先がリストであるために、返されるフィールドが複数回出現する場合、各出現は、各値にバインドされた this でテストされます。

特定のパスについて、祖先が null または [] の場合、そのフィールドには到達せず、そのパスの CEL 評価はスキップされます。つまり、評価は thisnull または null 以外の場合にのみ行われ、undefined の場合は行われません。

フィールド自体がリストまたはオブジェクトの場合、this は次の例に示すように、同じ構造(オブジェクトの場合は選択されたすべての子孫を含む)に従います。

mutation UpdateMovieTitle2($movieId: UUID!, $newTitle: String!) @auth(level: USER) @transaction {
  # Step 1: Query and check
  query {
    moviePermissions( # Now we query for a list of all matching MoviePermissions.
      where: {movieId: {eq: $movieId}, userId: {eq_expr: "auth.uid"}}
    # This time we execute the @check on the list, so `this` is the list of objects.
    # We can use the `.exists` macro to check if there is at least one matching entry.
    ) @check(expr: "this.exists(p, p.role == 'editor')", message: "You must be an editor of this movie to update title") {
      role
    }
  }
  # Step 2: Act
  movie_update(id: $movieId, data: {
    title: $newTitle
  })
}

複雑な式の構文

&& 演算子と || 演算子を組み合わせることで、より複雑な式を記述できます。

mutation UpsertUser($username: String!) @auth(expr: "(auth != null) && (vars.username == 'joe')")

以降のセクションでは、使用可能な演算子について説明します。

演算子と演算子の優先順位

演算子とそれぞれの優先順位については、次の表を参考にしてください。

次の表では、任意の式 ab、フィールド f、インデックス i を前提としています。

演算子 説明 関連性
a[i] a() a.f インデックス、呼び出し、フィールド アクセス 左から右
!a -a 単項否定 右から左
a/b a%b a*b 乗法演算子 左から右
a+b a-b 加法演算子 左から右
a>b a>=b a<b a<=b 関係演算子 左から右
a in b リストまたはマップ内の存在 左から右
type(a) == t 型の比較。t は、bool、int、float、number、string、list、map、timestamp、duration です。 左から右
a==b a!=b 比較演算子 左から右
a && b 条件付き AND 左から右
a || b 条件付き OR 左から右
a ? true_value : false_value 3 項式 左から右

認証トークン内のデータ

auth.token オブジェクトには次の値を含めることができます。

フィールド 説明
email アカウントに関連付けられているメールアドレス(存在する場合)。
email_verified ユーザーに email アドレスへのアクセス権があることが確認された場合は true。一部のプロバイダは、そのプロバイダが所有するメールアドレスを自動的に確認します。
phone_number アカウントに関連付けられている電話番号(存在する場合)。
name ユーザーの表示名(設定されている場合)。
sub ユーザーの Firebase UID。これはプロジェクト内で一意です。
firebase.identities このユーザーのアカウントに関連付けられているすべての ID の辞書。辞書のキーは、emailphonegoogle.comfacebook.comgithub.comtwitter.com のいずれかです。辞書の値は、アカウントに関連付けられている各 ID プロバイダの一意の識別子からなる配列です。たとえば、auth.token.firebase.identities["google.com"][0] にはアカウントに関連付けられている最初の Google ユーザー ID が含まれます。
firebase.sign_in_provider このトークンを取得するために使用されたログイン プロバイダ。custompasswordphoneanonymousgoogle.comfacebook.comgithub.comtwitter.com のいずれかの文字列です。
firebase.tenant アカウントに関連付けられている tenantId(存在する場合)。例: tenant2-m6tyz

JWT ID トークンの追加フィールド

次の auth.token フィールドにもアクセスできます。

カスタム トークンのクレーム
alg アルゴリズム "RS256"
iss 発行元 プロジェクトのサービス アカウントのメールアドレス。
sub 件名 プロジェクトのサービス アカウントのメールアドレス。
aud 対象 "https://identitytoolkit.googleapis.com/google.identity.identitytoolkit.v1.IdentityToolkit"
iat 発行時 現在の時間(UNIX エポック時刻からの秒数)
exp 有効期限 トークンの有効期限が切れる時間(UNIX エポック時刻からの秒数)。iat から最大 3,600 秒後の時間を設定できます。
注: これは、カスタム トークン自体の有効期限が切れる時間のみを制御できます。ただし、signInWithCustomToken() を使用してユーザーにログインさせた後は、セッションが無効になるかユーザーがログアウトするまで、デバイスにログインしたままになります。
<claims>(オプション) トークンに含めるオプションのカスタム クレーム。式の auth.token(または request.auth.token)でアクセスできます。たとえば、カスタム クレーム adminClaim を作成した場合は、auth.token.adminClaim でアクセスできます。

次のステップ