Firebase Authentication の基本的な使い方
Firebase Authenticationを使いこなすと、かなり楽に高品質な認証プロセスを組めるので、紹介します。
以下、5ステップに渡って順に説明していきます。主にiOSアプリ・自前APIサーバーの組み合わせ前提ですが、それ以外の構成とする場合でも参考になるはずです。
1. クライアントでFirebase Authenticationのtoken取得
認証方法は、以下に対応しています。
メール認証では確認メール送信、電話番号認証は認証コード発行部分までFirebase側でやってくれて、すごく良くできています👏
また、匿名認証も対応しているので、アプリをインストール・起動するだけでユーザー操作なしでtoken取得することもできます👏
また、上記記載以外の認証方法を提供したい場合も、ちょっと頑張ればできます。とはいえ、標準で用意されているものに比べるとサーバー対応の必要もあったりと少し面倒です。
以下でInstagramアカウントでの認証に対応するやり方が解説されています。同様のやり方で他のサービス対応もできます。
また、1ユーザーに複数のアカウントの認証を紐づけることもできます。
以上の何かしらの方法で認証後、tokenを取得します。やり方は以下のRetrieve ID tokens on clientsに記載されています。
また、このtokenは有効期限が1時間なことに注意です(後述の検証過程で有効期限切れかどうかチェックします)。
FIRUser.getIDToken(completion:) メソッドは、期限切れの場合にリフレッシュされたtokenを受け取れる(そうでない場合は保持しているtokenが返るはず)ので、自前で保持せずにAPIリクエストの度にこのメソッドを挟むのが良いかなと思っています。
Retrieves the Firebase authentication token, possibly refreshing it if it has expired.
https://github.com/firebase/firebase-ios-sdk/blob/5430b776ca6fea34d84dab09db39c51b51e551da/Firebase/Auth/Source/Public/FIRUser.h#L263-L271
2. tokenをAuthorization: Bearerヘッダに入れてAPIリクエスト
そのtokenをAuthorization: Bearerヘッダに入れるなどして自前APIサーバーにリクエストします。
curl -X "POST" "https://YOUR_API/authenticate" -H "Authorization: Bearer YOUR_TOKEN"3. サーバー側でそのtokenを検証 — Verification
サーバー側で、以下のVerify ID tokens using the Firebase Admin SDKに記載されている手順で、tokenを検証します。
ただ、Admin SDKは、現状以下の言語しか用意されていません。(将来的にはもっと増えるかもしれないのでをこちらからチェックしてみてください)。
それ以外の言語の場合は、Verify ID tokens using a third-party JWT libraryに記載の手順で自前実装します。
幸い、JWTライブラリはほとんどの言語にあるので、それを使えばそこまで難しく無いです。
SwiftPM対応のtoken検証ライブラリは僕の作ったものがこちらにあります💁(JWTライブラリは vapor/jwt を利用しました)
ドキュメントとNode.js版のソースを見ながら書いたので、きちんとした検証コードになっているはずです。
Vapor フレームワークを使っている場合、Project ID記載した設定ファイル置くだけでconfigからFirebaseVerifierインスタンスを取得できる、使いやすい作りになっています(他のフレームワーク使っている場合でも使えますが)。また、有効期限切れのtokenを許容するようなオプション引数も用意してあるので、Debug時は許容して開発しやすくできるようにも工夫しました。
4. 検証結果がOKだったらtokenに含まれるuser_idから、どのユーザーか識別 — Authentication
tokenをJWTサイトのEncodedの欄に貼るとデコードされたPayloadが確認できますが、そこの sub がFirebase AuthenticationのユーザーIDとなっているので、それを元にユーザーの識別ができます。
{
"iss": "https://securetoken.google.com/YOUR_PROJECT_ID",
"provider_id": "anonymous",
"aud": "YOUR_PROJECT_ID",
"auth_time": 1501381779,
"user_id": "USER_ID",
"sub": "USER_ID",
"iat": 1501654829,
"exp": 1501658429,
"firebase": {
"identities": {},
"sign_in_provider": "anonymous"
}
}ここで、通常そのFirebaseのユーザーIDに紐づいたレコードを生成・参照することになりますが、特に匿名認証対応する場合は、ID以外のフィールドをほぼ持たないテーブルを別途1つ用意するのが良いと思っています。
5. 認証状態(匿名か登録済みかなど)をチェックしてそのリソースへアクセスできるかチェック — Authorization
また、 provider_id や firebase/identities をチェックして、Firebase Authenticationにてどういう認証方法がなされたかが分かります。
これを元に、「このAPIは匿名認証はNGで登録が必要」のようなふるい分けができます。
以上のように、Firebase Authenticationを使うと一般的な認証プロセスを簡単に組めて素晴らしいです。ただ、Firebaseにロックインされるので、サービスが終了したら移行などかなり辛いことにはなるはずです。個人的にはFirebaseは数年はサービス続くのは間違いないと踏んでいるので、積極的にロックインされにいってます🏃
