Firebaseのカスタムクレームを実装する
2022年04月22日 8:20
こんにちは、ISSUEの寒河江です。
今回はfirebaseのカスタムクレームの実装について書きました。先日実装する機会があり、ハマりやすいポイントがあるなと感じたので基本的な使い方と共にお話しできたらと思います。
Firebase Authenticationで提供されている仕組みで、ユーザーごとにカスタム属性をセットすることができます。これによりさまざまなアクセス制御戦略を実装することができます。公式では以下の例が紹介されています。
要はカスタムクレームに認証に使える情報(user_id, adminかどうか)などをセットしてアクセス制限を区別できるようにするため使われます。Goで言うとcontextにリクエストスコープの値(userIDなど)をセットしてserviceに必要な情報を渡すイメージに近いと思います。
カスタムクレームはAdmin SDKにより設定することができます。カスタムクレームには機密データが含まれている可能性があるため、Firebase Admin SDKによって特権サーバー環境からのみ設定される必要があります。
以下はGoの例になります。
セット方法はこれだけでとても簡単です。
カスタムクレームの実装方法は下記になります。
取得方法もとても簡単です。
カスタムクレームにはアクセス制御に関するデータのみを格納します。オブジェクトやその他大きなデータはfirestoreやgoogle storageへデータを格納することがおすすめされています。(参考)
カスタムクレームは更新しただけではフロントへ伝播されません。最新のカスタムクレームがセットされたIdTokenを取得するには、IdTokenのリフレッシュが必要になります。
公式にあるようにカスタムクレームの伝播方法は以下です。
currentUser.getIdToken(true)
を呼び出して ID トークンが強制的に更新する。カスタムクレームを更新した後に、すぐにIdTokenを失効させユーザーに再認証を求める方法です。ただ実際は、IdTokenを失効させることはできません。IdTokenをリフレッシュさせるリフレッシュトークンを失効させます。
こちらのメリデメは下記になります。
デメリット
メリット
サービス内で利用頻度の高い機能で実装するのは避けた方が良さそうです。
こちらが実装サンプルです。
IdTokenの検証にはVerifyIDTokenではなくVerifyIDTokenAndCheckRevokedを利用しましょう。VerifyIDTokenだとrefreshトークンが失効したかは確認していません。なのでIdTokenの有効期限(1時間)が切れていない場合はカスタムクレームが更新されていない状態となっていまいます。
VerifyIDTokenAndCheckRevokedを利用したIdToken検証
`
currentUser.getIdToken(true)
を呼び出して ID トークンが強制的に更新する。こちらは最も簡単な方法です。フロント側でIdTokenをリフレッシュすることができます。しかし、リフレッシュ処理はやや重たい処理となるので、カスタムクレームを更新した場合のみに発火するように実装をする必要があります。また実際はcurrentUser.getIdToken(true)
したとしてもリフレッシュ済みのIdTokenを取得するには画面をリロードする必要があります。フロント側のレンダリング設計によっては実装が難しい場合もあるのでよく検討することをおすすめします。
https://firebase.google.com/docs/auth/admin/custom-claims?hl=ja
以上Firebaseのカスタムクレームを扱う上での注意点になります!
診断を受けるとあなたの現在の業務委託単価を算出します。今後副業やフリーランスで単価を交渉する際の参考になります。また次の単価レンジに到達するためのヒントも確認できます。
目次を見る