LINEログイン画面に遷移するためのページ
- stateとnonceを発行してLINEログイン画面に遷移する
LINEログイン画面からredirectされるページ
- stateの検証やエラーレスポンスを受け取ったときの処理
- アクセストークンを受け取りCloudFunctionsを呼び出す
- カスタムトークンを用いてログインする
LINE PLATFORMとFirebase Authenticationを駆使してカスタムトークンを発行する処理
- CloudFunctionsで作成する

satjopg

流れとしては問題ないことを確認。
FirebaseのカスタムトークンをCloud Functionsで発行する際に追加の設定が必要になる。

その1 カスタムトークンの発行権限をCloud Functionsのアカウントに付与する

公式ページのトラブルシューティングには以下のように書かれています。

問題のサービスアカウント（通常は {project-name}@appspot.gserviceaccount.com）に「サービスアカウントトークン作成者」の IAM ロールを付与することです。

この手順に従い、IAMで「サービスアカウントトークン作成者」ロールを{project-name}@appspot.gserviceaccount.comに割り当てます。

付与したがPermission Deniedになる場合...

こちらのCloud Functions のデフォルトのサービスアカウントというリンクを飛ぶと
このページに飛びます

そのページを読むとランタイムサービスアカウントはPROJECT_ID@appspot.gserviceaccount.comと書かれています。
つまりCloud Functionsのアカウントであるこちらにも「サービスアカウントトークン作成者」ロールを割り当てる必要がありそうです。

こちらのアカウントはIAMの「Google 提供のロール付与を含みます」にチェックを入れることで表示されます。
(名前 Google Cloud Functions Service Agent というアカウントです)

このアカウントにも「サービスアカウントトークン作成者」ロールを割り当てます。

その2 IAM APIを有効にする

こちらも公式のトラブルシューティングに書かれています

IAM Service Account Credentials APIを有効にします。
※ 有効前にプロジェクトが正しいかどうかの確認をしてください。

satjopg

考えないといけないことと所感

考えないといけないこと

LINEのユーザIDとFirebaseのユーザIDを一緒にするかどうか

LINEで登録したユーザが退会し、再度登録ができる仕様の場合
退会前と同じユーザとして扱うかどうかを考える。
※ Firebase側で用意されているプロバイダーの場合、異なるユーザIDが発行される。

同じユーザとして扱う場合はLINEのユーザIDをFirebaseのユーザIDとして良い。
異なるユーザとして扱いたい場合は以下が必要となる

LINEのユーザIDとは別にFirebaseのユーザIDを発行する
この2つのIDを紐付ける

方法としてはDB(Firestoreなど)に保存するかカスタムクレームにLINEのIDを保存しておくか
などが考えられる。

所感

カスタムトークン発行時の設定に詰まった以外は特に問題なくできた。
OIDC(ないしはoauth2)については他サービスと連携する上で必須なので知っておく必要がある。

まあ、そもそもカスタムトークンによる認証については
Firebase側で事前に連携できるプロバイダーと比較すると当然だが
開発のコストはかかるし連携先の最新情報を追うなど管理コストもかかるので
そのへんはしっかりと認識すべきである。
なので、ちゃんとそのサービスを使った認証が使われる見込みがあるか
どうかの事前調査を行った上で導入すべきである。