こんにちは、イケメンエンジニアです。
大手通信業界でWebアプリ開発をしていると、 BtoB向けでもBtoC向けでもほぼ必ず出てくるのが フェデレーション認証です。
「Googleログインを実装したい」
「自社IdPとSSO連携したい」
「OIDC対応できますか？」
こういった相談ができるエンジニアは、確実に市場価値が上がります。
今回は、 Google認証（OpenID Connect）を自分のアプリに実装するケース を例に、フェデレーション認証の仕組みを整理します。
1. フェデレーション認証とは？
フェデレーション認証とは、ざっくり言うと
「ログイン（本人確認）を、自分のアプリではなく外部の信頼できるサービスに任せる」
という設計です。
典型例が Googleログイン。
あなたのアプリは「ユーザーのパスワード」を一切扱わず、Googleが本人確認した結果だけを受け取ります。
ローカル認証との違い
| 項目 | ローカル認証（自前ログイン） | フェデレーション認証（Googleログインなど） |
|---|---|---|
| パスワード管理 | 自アプリが保持・管理 | 外部IdP（Googleなど）が管理 |
| セキュリティ事故の責任 | 基本ぜんぶ自分 | IdPと分担（ただし自アプリ側も責任あり） |
| SSO（シングルサインオン） | 実装難しめ | 仕組み上やりやすい |
| 初期実装 | 単純に見える（が落とし穴多い） | 設定は多いが王道で堅い |
| 目的 | 自アプリのアカウントを自前で作る | 外部の「本人確認」を利用する |
ポイントはこれです。
フェデレーション認証は「本人確認」を自分でやらない設計。
2. 登場人物を整理する
- User：ユーザー
- Client：あなたのWebアプリ
- IdP（Identity Provider）：Google
今回の例では、GoogleがIdPです。
3. 使われるプロトコル：OIDCとは？
Googleログインは、 OIDC（OpenID Connect）というプロトコルを使用します。
OIDCはOAuth 2.0の上に構築された「認証用プロトコル」です。
ポイントは、 IDトークン（JWT）でユーザー情報を安全に受け取ること。
4. Googleログインの処理フロー（OAuth 2.0から理解する）
まず大前提です。
OAuth 2.0は「ログインの仕組み」ではありません。
OAuth 2.0は「権限をアプリに委譲する仕組み」です。
Googleログインの裏側では、
- OAuth 2.0で「権限」を取得
- OIDCで「本人確認」を取得
という順番で動いています。
4-1. OAuth 2.0とは何か？
OAuth 2.0は一言で言うと：
「ユーザーのパスワードを渡さずに、アプリに限定的な権限を渡す仕組み」
例えば：
- あなたのアプリが
- ユーザーのGoogle情報を取得したい
でも、
- パスワードを預かるのは危険
- Googleの資格情報を保存するのは論外
そこでOAuth 2.0が登場します。
4-2. なぜリダイレクトするのか？
ユーザーが「Googleでログイン」を押すと、
アプリはGoogleの画面へリダイレクトします。
https://accounts.google.com/o/oauth2/v2/auth
理由はシンプルです。
👉 パスワードを自分のアプリで入力させないため。
ログインは必ずGoogleのドメイン上で行われます。
4-3. Authorization Code Flow（安全な標準方式）
Googleログインで使われるのは
Authorization Code Flow です。
流れはシンプルです。
① ユーザーをGoogleへリダイレクト
② ユーザーがGoogleでログイン
③ Googleが code（認証コード）を返す
④ サーバーがその code をGoogleに送り、トークンを取得
ここで重要なのは：
- ブラウザでは「code」だけ受け取る
- 本物のトークンはサーバー間通信で取得する
これが安全設計の核心です。
4-4. Access Tokenとは？
Access Tokenは：
「このアプリは、ユーザーの代わりに○○していい」証明書
例えば：
- メールアドレス取得
- Google API呼び出し
ただしこれはログイン情報ではありません。
4-5. ここでOIDCが追加される
OAuth 2.0だけでは
「この人が誰か」は分かりません。
そこでOIDCは：
- IDトークン（JWT）
を追加します。
このIDトークンを検証して
初めて「ログイン成功」になります。
5. なぜ安全なのか？
Googleログインが強い理由は「気合」ではなく「構造」です。
- パスワードを保持しない
→ 漏洩リスクが激減 - IDトークンが署名付き
→ 改ざんしたらバレる - TLS（HTTPS）で通信
→ 盗聴に強い - state/nonceなどの防御が標準で用意
→ よくある攻撃を潰しやすい - 認証の責任をGoogleと分担できる
→ 自前ログインより堅くしやすい
6. フェデレーション認証のメリット
- パスワード管理不要
- セキュリティ水準が上げやすい
- SSOが実現しやすい
- BtoBで企業IdP連携（Azure AD/Oktaなど）に拡張できる
Googleログインを理解すると、企業SSOに横展開しやすいです。
7. デメリット
- 外部依存（Google障害、仕様変更の影響）
- 設定がやや複雑（リダイレクトURI、スコープ、クライアント種別など）
- トークン検証を雑にすると事故る（“受け取ったJWTをそのまま信じる”が最悪）
8. 実務での活用シーン
BtoCサービス
- 登録が速い（離脱が減る）
- パスワード忘れ対応が減る
BtoB SaaS
- 企業IdPとSSO連携（Azure AD / Oktaなど）
- 退職・異動時のアカウント統制が効く
まとめ｜まずは「OAuth 2.0はログインじゃない」を覚える
OAuth 2.0は 権限委譲（認可）
OIDCは OAuth 2.0の上に 本人確認（認証） を追加
Googleログインは IDトークン（JWT）を検証してログイン成立
ここが腹落ちすると、フェデレーション認証は一気に得意分野になります。
コメント