はじめに
第1回の「設計編」では、FirebaseとSQL Serverを疎結合に保つ「認証と認可の分離」について解説しました。第2回となる今回は、フロントエンドから送られてきた認証情報（IDトークン）を、サーバーサイドでどうやって安全に受け取り、既存のSQL Serverと紐付けるのか、具体的な実装の考え方を解説します。
概要：
本記事では、サーバーサイド専用ライブラリである「Firebase Admin SDK」の役割と、IDトークン（JWT）検証の裏側の仕組み、そして既存データベースと連携する際の「システム未登録」のハンドリング方法について解説します。
結論：
サーバー側での検証・操作には、必ずクライアントSDKではなく「Admin SDK」を使用する。
送られてきたIDトークンを検証し、中から取り出したUIDを使ってSQL Serverを検索する「二重の関門」を設ける。
Firebaseのトークン（1時間）と、自社サーバーのCookieの有効期限の二重管理に注意する。
1. Firebase Admin SDK とは（特権ツール）
フロントエンド（ブラウザ）でユーザーがログインすると、Firebaseから「IDトークン」という証明書が発行されます。この証明書を自社サーバーに送って権限を確認するのですが、サーバー側でFirebaseとやり取りするために使うのが Firebase Admin SDK です。
Admin SDKは、クライアント向けのJavaScript SDKとは根本的に異なり、サーバー上で動く 「特権的な操作」 が可能なSDKです。（C#環境ではNuGetパッケージ FirebaseAdmin として提供されています）
できることの例：
・IDトークンの検証（Googleの公開鍵で署名検証し、UIDを取り出す）
・UIDを直接指定してのユーザー作成・削除
・パスワードを無視した強制ログイン（カスタムトークンの発行）
・全ユーザーの一覧取得
💡 【初心者向け解説】合鍵とマスターキー
クライアントSDKは、自分の部屋だけを開けられる「合鍵」です。
Admin SDKは、マンションの管理人だけが持っている「マスターキー」です。Admin SDKを使えば、全住民の部屋を開けたり、新しい鍵を作ったりと何でもできてしまうため、絶対にブラウザ側（フロントエンド）のコードに組み込んではいけません。
2. トークン検証の仕組み（裏側で起きていること）
フロントエンドから送られてきたIDトークン（JWT）は、Admin SDKの VerifyIdTokenAsync などのメソッドに渡すだけで、一発で本物かどうかを検証してくれます。
しかし、「このメソッドが裏で何をやっているか」を理解しておくと、障害時の原因調査が格段に楽になります。
🚨 トークン検証の4ステップ
１. ヘッダー部のデコード: トークンがどのアルゴリズムで暗号化（署名）されているかを確認します。
２. 署名部の検証: Googleが公開している「公開鍵」をインターネット経由で取得し、トークンが本当にGoogleによって発行され、改ざんされていないかを照合します。
３.ペイロードの検証: トークンの「有効期限が切れていないか」「発行元は正しいか」「自分のプロジェクト（Project ID）宛てのものか」を厳密にチェックします。
４.UIDの取り出し: すべてのチェックを通過して初めて、トークンの中身から decodedToken.Uid として安全にユーザーIDを取り出します。
💡 公開鍵はキャッシュされる
「毎回Googleに公開鍵を取りに行ったら、通信が遅くなるのでは？」と心配になるかもしれませんが、Admin SDKが自動的にGoogleの公開鍵を一定時間キャッシュ（一時保存）してくれるため、毎リクエストで重いネットワーク通信が走るわけではありません。
3. 認証と認可の紐付けロジック（二重の関門）
トークンの検証が無事に終わり、確実な UID（SQL Serverに登録されているはずのGUID）が手に入りました。次に行うのが、既存のSQL Serverとの照合です。
ここで絶対に忘れてはいけないのが 「システム未登録」のハンドリング です。
Firebase認証 ──→ 成功（有効なUIDあり）
↓
SQL Server照合 ──→ UIDが存在しない！ ❌（ここで401/403エラーを返す）
↓ 存在する
ロール・権限を取得してログイン成功（Cookie等を発行）⭕
もし「Firebase側にはユーザーが存在する（ログインできた）」けれど、「SQL Server側にはそのUIDのユーザー情報が存在しない、あるいは削除されている」場合、そのユーザーはシステムを利用できません。
これが「認証（Firebase）」と「認可（SQL Server）」を分離したことで生まれる 「二重の関門」 の仕組みです。
💡 【初心者向け解説】パスポートはあるけど、ビザがない
Firebaseの検証通過は「本物のパスポートを持っていますね」という確認です。しかし、SQL Serverにデータがない状態は「でも、うちの国に入るためのビザ（入国許可証）が登録されていませんよ」という状態です。どちらか片方でも欠けていたら、システムには入れません。
4. 注意点：IDトークンの有効期限は「1時間」
最後に、セッション管理の罠について触れておきます。
Firebaseが発行するIDトークンの有効期限は、セキュリティ上の理由から 固定で「1時間」 に設定されており、これを延ばすことはできません。
もし、フロントエンドとFirebaseだけで完結するアプリなら、JS SDKが裏で自動的にトークンを更新（リフレッシュ）してくれますが、自社サーバーと連携する場合は注意が必要です。
⚠️ トークンとCookieの二重管理
今回は、「FirebaseのIDトークンを使って、自社サーバーが独自のログインCookieを発行する」という設計を想定しています。
そのため、ブラウザが持つCookieの有効期限（例：24時間）と、Firebaseのトークンの有効期限（1時間）の2つが存在することになります。
長時間の作業を許容する場合、Cookieが生きていればOKとするか、途中でFirebaseのトークンを再取得（getIdToken(true)）してサーバーに送り直すか、システムの要件に合わせてセッション管理を設計する必要があります。
まとめ
サーバーサイドでの連携は、Admin SDKという強力なツールを使うことで非常にシンプルに実装できます。
Admin SDKは特権ツール。絶対にクライアント側に漏らしてはいけない。
トークン検証の仕組みを理解し、安全にUIDを取り出す。
Firebaseで認証できても、SQL Serverにデータがなければ弾く（二重の関門）。
トークンとCookie、2つの有効期限を意識してセッションを設計する。
次回は、最大の難関である「データの不整合を防ぐトランザクションと補償処理（ロールバック）」について解説します！