Firebase Data Connect は、次のような堅牢なクライアントサイド セキュリティを提供します。
- モバイル クライアントとウェブ クライアントの認可
- 個々のクエリレベルとミューテーション レベルの認可制御
- Firebase App Check によるアプリ構成証明。
Data Connect は、次の機能でこのセキュリティを拡張します。
- サーバーサイド認可
- IAM を使用した Firebase プロジェクトと Cloud SQL ユーザーのセキュリティ。
クライアントのクエリとミューテーションを承認する
Data Connect は Firebase Authentication と完全に統合されているため、データにアクセスするユーザーに関する豊富なデータ(認証)を設計で使用して、そのユーザーがアクセスできるデータ(認可)を制御できます。
Data Connect には、クエリとミューテーション用の @auth
ディレクティブがあり、オペレーションの認可に必要な認証レベルを設定できます。このガイドでは、@auth
ディレクティブとその例について説明します。
さらに、Data Connect はミューテーションに埋め込まれたクエリの実行をサポートしているため、データベースに保存した追加の認可条件を取得し、@check
ディレクティブでこれらの条件を使用して、囲むミューテーションが承認されているかどうかを判断できます。この認可ケースでは、@redact
ディレクティブを使用して、ワイヤー プロトコルでクライアントにクエリ結果を返すかどうか、および生成された SDK で埋め込みクエリを省略するかどうかを制御できます。これらのディレクティブの概要と例をご覧ください。
@auth
ディレクティブについて
@auth
ディレクティブをパラメータ化して、一般的なアクセス シナリオの多くに対応するいくつかのプリセット アクセスレベルのいずれかに従うようにできます。これらのレベルは、PUBLIC
(いかなる種類の認証も行わずにすべてのクライアントからのクエリとミューテーションを許可)から NO_ACCESS
(Firebase 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
が適切なアクセスレベルであるユースケースもあります。繰り返しになりますが、アクセスレベルは常に出発点であり、堅牢なセキュリティを確保するには追加のフィルタと式が必要です。
このガイドでは、USER
と PUBLIC
でビルドする方法の例を示します。
モチベーションを高める例
次のベスト プラクティスの例は、特定のコンテンツが支払いプランでロックされているブログ プラットフォームの次のスキーマを参照しています。
このようなプラットフォームでは、Users
と Posts
をモデル化している可能性があります。
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.uid
を authorUid
フィールドとして各新しい 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
アクセスレベルを使用しないでください
このガイドで何度か説明したように、USER
、USER_ANON
、USER_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 Connect で App Check を有効にして、そのクライアント SDK をアプリに含める方法については、App Check の概要をご覧ください。
@auth(level)
ディレクティブの認証レベル
次の表に、すべての標準アクセスレベルとその CEL の同等を示します。認証レベルは、広いレベルから狭いレベルの順に表示されます。各レベルは、次のレベルに一致するすべてのユーザーを対象としています。
レベル | 定義 |
---|---|
PUBLIC |
このオペレーションは、認証の有無にかかわらず誰でも実行できます。 考慮事項: データはどのユーザーでも読み取ったり変更したりできます。 Firebase では、商品やメディアのリスティングなど、一般公開されているデータにはこのレベルの認可をおすすめします。ベスト プラクティスの事例と代替手段をご覧ください。 @auth(expr: "true") と同等
@auth フィルタと式は、このアクセスレベルと組み合わせて使用できません。このような式は、400 エラーで失敗します。 |
USER_ANON |
Firebase Authentication で匿名でログインしたユーザーを含む、識別されたすべてのユーザーは、クエリまたはミューテーションを実行する権限があります。 注: USER_ANON は USER のサブセットです。
考慮事項: このレベルの認可では、クエリとミューテーションを慎重に設計する必要があります。このレベルでは、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 メソッドに基づいています。そのため、このレベルでは USER や USER_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
vars
(request.variables
の別名)auth
(request.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 評価はスキップされます。つまり、評価は this
が null
または 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')")
以降のセクションでは、使用可能な演算子について説明します。
演算子と演算子の優先順位
演算子とそれぞれの優先順位については、次の表を参考にしてください。
次の表では、任意の式 a
と b
、フィールド 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 の辞書。辞書のキーは、email 、phone 、google.com 、facebook.com 、github.com 、twitter.com のいずれかです。辞書の値は、アカウントに関連付けられている各 ID プロバイダの一意の識別子からなる配列です。たとえば、auth.token.firebase.identities["google.com"][0] にはアカウントに関連付けられている最初の Google ユーザー ID が含まれます。 |
firebase.sign_in_provider |
このトークンを取得するために使用されたログイン プロバイダ。custom 、password 、phone 、anonymous 、google.com 、facebook.com 、github.com 、twitter.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 でアクセスできます。 |
次のステップ
- Firebase Data Connect には、特権環境からクエリとミューテーションを実行できる Admin SDK が用意されています。
- IAM セキュリティの詳細については、サービスとデータベースの管理ガイドをご覧ください。