メタCセキュリティ物語〜認証とシングルサインオン編〜

2026年1月4日
セキュリティ資格学習
2回
0件

セキュリティ資格学習

この記事は、セキュリティ資格学習のために、AI（Claude）と共同で作成したコンテンツです。 ※間違った解釈がある可能性があります。

この記事の目的セキュリティの専門用語は、カタカナや略語が多く、初学者にとって非常に取っつきにくいものです。そこで、専門家じゃなくてもわかるようにストーリー風に構成してみました。

1 プロローグ：パスワードの限界
2 第1章：AAAフレームワーク
3 第2章：チャレンジレスポンス認証
4 第3章：シングルサインオン（SSO）
5 第4章：SAML（アイデンティティ連携）
6 第5章：OAuth 2.0
7 第6章：OpenID Connect
8 第7章：FIDO（パスワードレス認証）
9 第8章：結城の新たな攻撃
10 第9章：守られた二人
11 エピローグ：認証の未来
12 🎓 用語まとめ
13 📚 次のステップ

プロローグ：パスワードの限界

🔐 パスワード管理の悪夢

【1週間前】

慎也は、自分のパスワード管理に頭を抱えていた。

メタCのアカウントが乗っ取られた事件の後、里見からこう言われていた。

「慎也、全部のサービスでパスワード変えて。しかも、全部違うパスワードにしてね」

「え…全部？」

慎也が使っているサービスをリストアップすると：

1. メタC
2. Google（Gmail）
3. Twitter（X）
4. Amazon
5. 楽天
6. Netflix
7. Spotify
8. GitHub
9. Discord
10. LINE
11. 銀行アプリ
12. 会社のVPN
13. 社内システム
14. AWS
15. Slack
...（他にも20以上）

「全部で35個もある…」

しかも、里見からの要求は厳しかった。

パスワードの条件:

12文字以上
大文字・小文字・数字・記号を含む
辞書にある単語を使わない
サービスごとに全く違うパスワード
定期的に変更

「こんなの覚えられないよ…」

📝 パスワードメモの危険

慎也は、どうしても覚えられず、こっそりメモ帳に書いていた。

メタC: S@t0m1_L0v3_2024!
Google: G00gl3_M41l_P@ss!
Amazon: Am@z0n_Sh0p_2024

その日の午後、会社でメモ帳を開いたまま席を離れた。

戻ってきたとき、同僚が覗き込んでいた。

「山本さん、これパスワード？」

「え、あ、その…」

慎也の顔が真っ赤になる。

「ダメだよ、こんなところに書いちゃ。誰でも見えるじゃん」

その夜、里見に報告すると、呆れられた。

「慎也…せっかく強いパスワード作ったのに、メモしてたら意味ないよ」

「だって、覚えられないんだもん…」

💑 里美の優しい提案

里見が微笑む。

「大丈夫。今日はもっといい方法を教えるね」

「本当？」

「うん。パスワードを使わない認証とか、1回のログインで全部使える仕組みとか」

「え、そんなのあるの？」

「あるよ。これから一緒に勉強しよう」

慎也と里見は、メタCの綺麗なワールドに移動した。

星空の下、二人だけの勉強会が始まる。

第1章：AAAフレームワーク

🔑 認証・認可・アカウンティング

「ねえ、里美。そもそも『ログイン』って何をしてるの？」

「いい質問！実は、ログインには3つのステップがあるんだ」

里見が図を描き始める。

「これをAAAフレームワークって言うの」

「トリプルエー？」

「そう。3つのAの頭文字だよ」

AAAフレームワーク（トリプルエーフレームワーク）とは:

正式名称: Authentication, Authorization, Accounting

3つのステップ:

①Authentication（オーセンティケーション：認証）

「あなたは誰？」を確認
本人確認

②Authorization（オーソライゼーション：認可）

「あなたは何ができる？」を決定
権限の確認

③Accounting（アカウンティング：アカウンティング）

「あなたは何をした？」を記録
操作ログの記録

🎭 具体例で理解

「例え話で説明するね」

里見が身近な例を出す。

例：遊園地に入る時

①Authentication（認証）

受付: 「チケットを見せてください」
あなた: 「はい、これです」
受付: 「確認しました。どうぞ」

→ 本人確認（チケット保持者＝本人）

②Authorization（認可）

受付: 「このチケットは大人用なので、全アトラクション利用できます」
     「ただし、VIPラウンジは使えません」

→ 権限の付与（何ができるか）

③Accounting（アカウンティング）

受付: 「入場時刻：14:30、チケットNo.12345」
     （システムに記録）

→ 利用履歴の記録

「なるほど！遊園地もAAAなんだ」

「そう。これがログインの基本なんだよ」

🔐 メタCでのAAA

「じゃあ、メタCでは？」

里見が説明を続ける。

メタCのログインプロセス:

①Authentication（認証）

1. ユーザー名: shinya_yamamoto
2. パスワード: ••••••••••
3. 二段階認証コード: 123456

→ 本人確認OK

②Authorization（認可）

権限確認:
- ワールド作成: OK
- ワールド公開: OK
- 管理者画面: NG（一般ユーザーのため）
- 他人のアカウント削除: NG

→ 一般ユーザー権限を付与

③Accounting（アカウンティング）

ログ記録:
[2024-01-02 23:00:00] shinya_yamamoto ログイン成功
[2024-01-02 23:05:12] ワールド作成: "星空の展望台"
[2024-01-02 23:30:45] チャット送信: satomi宛
[2024-01-03 01:00:00] ログアウト

→ 全操作を記録

「全部記録されてるんだ」

「そう。だから、結城が不正アクセスしたのもログに残ってるの」

第2章：チャレンジレスポンス認証

🎯 パスワードを送らない認証

「ねえ、里美。パスワードを送るのって、危険じゃない？」

「鋭い！その通りなんだ」

「だって、通信を盗聴されたらバレちゃうよね」

「そこで、チャレンジレスポンス認証って方法があるんだよ」

「チャレンジレスポンス？」

チャレンジレスポンス認証とは:

一言で言うと: パスワードを直接送らずに本人確認する方法

仕組み:

【サーバー】                    【クライアント】
    |                                  |
    | ①「問題（チャレンジ）」          |
    | 　　例: "123456"を送る            |
    |--------------------------------->|
    |                                  |
    |                      ②パスワードと問題を
    |                        組み合わせて計算
    |                        Hash(パスワード + "123456")
    |                        = "ABC789..."
    |                                  |
    | ③「答え（レスポンス）」          |
    |   "ABC789..."                    |
    |<---------------------------------|
    |                                  |
④サーバーも同じ計算をして比較
  Hash(保存してるパスワード + "123456")
  = "ABC789..." → 一致！ログインOK

「パスワードは送らないんだ！」

「そう。答え（ハッシュ値）だけ送るの」

🎲 例え話

「合言葉のクイズみたいなものだよ」

例：秘密基地に入る時

普通の方法（パスワード認証）:

門番: 「合言葉は？」
あなた: 「ひまわり」
門番: 「正解！入って」

→ 盗聴されたら「ひまわり」がバレる

チャレンジレスポンス:

門番: 「今日のお題は『花』。合言葉から連想される別の花を答えて」
あなた: （心の中で）「合言葉は『ひまわり』...黄色い花...じゃあ『たんぽぽ』！」
あなた: 「たんぽぽ」
門番: 「正解！」

→ 盗聴しても「たんぽぽ」しか分からない
→ 次は別のお題だから使えない

「なるほど！毎回問題が違うから、盗聴しても意味ないんだ」

「正解！」

🔒 HMACとの組み合わせ

「実際には、HMACを使うことが多いよ」

「HMAC？前に聞いた気がする」

「秘密鍵を使ったハッシュだよ」

チャレンジレスポンス + HMAC:

サーバー: チャレンジ = "random_12345"
クライアント: レスポンス = HMAC(パスワード, "random_12345")
サーバー: 保存してるパスワードで同じ計算 → 照合

「これなら、パスワードが通信経路に乗らないね」

「その通り！」

第3章：シングルサインオン（SSO）

😫 パスワード地獄からの解放

「ねえ、里美。35個もパスワード覚えるの無理だって」

慎也が泣きそうな顔で言う。

「大丈夫。SSOを使えば、1回のログインで全部使えるよ」

「え！本当？」

「うん。シングルサインオンって言うんだ」

SSO（エスエスオー）とは:

正式名称: Single Sign-On（シングルサインオン）

一言で言うと: 1回のログインで、複数のサービスが使える仕組み

例え話:

ホテルの部屋の鍵カード1枚で
- 部屋
- プール
- ジム
- レストラン全部使える

メリット:

パスワード管理が楽
セキュリティが向上（パスワードの使い回し防止）
利便性向上

デメリット:

1つのパスワードが破られると全部危険
SSOサーバーがダウンすると全サービスが使えない

🎫 SSOの2つのタイプ

「SSOには、大きく分けて2つのタイプがあるんだ」

①エージェント型（チケット型）

各サーバーに「エージェント」というソフトをインストール
チケットを使って認証

②リバースプロキシ型

入り口に「関所」を設置
関所で認証してから、各サービスに転送

「どっちが良いの？」

「それぞれメリット・デメリットがあるから、場合による。順番に説明するね」

🎟️ エージェント型SSO（Kerberos）

「エージェント型の代表はKerberosだよ」

「ケルベロス？」

「そう。ギリシャ神話の三つ首の番犬の名前だよ」

Kerberos（ケルベロス）とは:

一言で言うと: チケットを使ったエージェント型SSO

仕組み:

【利用者】         【認証サーバー】      【各サービス】
   |                    |                    |
   | ①ログイン         |                    |
   |------------------>|                    |
   |                    |                    |
   | ②チケット         |                    |
   |<------------------|                    |
   |                    |                    |
   | ③チケット提示                          |
   |---------------------------------------->|
   |                    |                    |
   |                    |      ④チケット確認  |
   |                    |<-------------------|
   |                    |                    |
   |                    |      ⑤認証OK       |
   |                    |------------------->|
   |                    |                    |
   | ⑥サービス利用                          |
   |<----------------------------------------|

特徴:

各サーバーにエージェント（チケット確認ソフト）が必要
チケットには有効期限がある（通常8時間）
チケットは暗号化されている

例え話:

遊園地の1日券みたいなもの

①入場時にチケット購入（ログイン）
②チケットをもらう
③各アトラクションでチケット提示
④係員がチケット確認
⑤利用OK

使われてる場所:

Windows Active Directory
大学のキャンパスネットワーク
企業の社内システム

🚪 リバースプロキシ型SSO

「もう一つの方式がリバースプロキシ型」

「リバースプロキシ？」

「入り口に関所を設置して、そこで認証する方式だよ」

リバースプロキシ型SSOとは:

一言で言うと: 入り口で一括認証してから各サービスに転送

仕組み:

【利用者】    【リバースプロキシ】     【各サービス】
   |               |                      |
   | ①アクセス    |                      |
   |------------->|                      |
   |               |                      |
   | ②ログイン要求|                      |
   |<-------------|                      |
   |               |                      |
   | ③認証情報    |                      |
   |------------->|                      |
   |               |                      |
   |         ④認証OK                     |
   |         ⑤リクエスト転送             |
   |               |--------------------->|
   |               |                      |
   |               |      ⑥レスポンス    |
   |               |<---------------------|
   |               |                      |
   | ⑦レスポンス  |                      |
   |<-------------|                      |

特徴:

サービス側に手を加えなくていい
関所（プロキシ）の設定だけで実現
シンプル

例え話:

マンションの入り口みたいなもの

①マンション入り口で認証（オートロック）
②認証されたら中に入れる
③各部屋は鍵なしで入れる（内部は信頼）

使われてる場所:

企業のWebアプリケーション群
クラウドサービスへのアクセス制御

⚖️ エージェント型 vs リバースプロキシ型

「どっちを選べばいいの？」

里見が比較表を作る。

項目	エージェント型	リバースプロキシ型
導入の手間	各サーバーに設定必要	プロキシだけ設定
セキュリティ	高い（各サーバーで確認）	中（関所だけ）
障害の影響	一部だけ影響	全体に影響
既存システム	改修必要	改修不要
代表例	Kerberos	NGINX, Apache

「新しいシステムならリバースプロキシ型が楽、既存システムならエージェント型が安全、って感じかな」

「正解！」

第4章：SAML（アイデンティティ連携）

🌐 外部サービスとの連携

「ねえ、里美。メタCでGoogleアカウントでログインできるよね」

「そう！あれがSAMLだよ」

「サムル？」

「アイデンティティ連携って言うんだ」

アイデンティティ連携とは:

一言で言うと: 複数のサービスで同じログイン情報を使えるようにする技術

メリット:

ユーザー：パスワード管理が楽
サービス提供者：認証の手間を省ける
企業：統一的なアクセス管理

主な技術:

SAML: 企業向け、XMLベース
OAuth 2.0: 認可に特化
OpenID Connect: OAuth 2.0の拡張

🔑 IdPとSP

「アイデンティティ連携には、2つの役割があるんだ」

IdP（アイディーピー）:

Identity Provider（アイデンティティプロバイダー）
認証をする側
例：Google、Microsoft、Facebook

SP（エスピー）:

Service Provider（サービスプロバイダー）
認証をされる側
例：メタC、Slack、Zoom

例え話:

【学生証でコンビニ払い】

大学（IdP）:
- 学生証を発行
- 「この人は本学の学生です」と証明

コンビニ（SP）:
- 学生証を確認
- 学割を適用
- 大学に「本人確認お願いします」と問い合わせなくていい

📨 SAML（サムル）

SAML（サムル）とは:

正式名称: Security Assertion Markup Language

一言で言うと: IdPとSP間で認証情報を安全に交換するためのプロトコル

バージョン: SAML 2.0が現在の標準

特徴:

XML形式でデータ交換
企業向け（厳格な認証）
通信プロトコル：HTTP、SOAP

🔄 SAMLの流れ

里見が図を描く。

【ブラウザ】        【SP: メタC】       【IdP: Google】
    |                    |                    |
    | ①メタCにアクセス  |                    |
    |------------------->|                    |
    |                    |                    |
    |  ②認証要求メッセージ（リダイレクト）   |
    |<-------------------|                    |
    |                    |                    |
    | ③認証要求メッセージをGoogleに送信     |
    |---------------------------------------->|
    |                    |                    |
    |              ④「Googleでログインしてください」
    |<----------------------------------------|
    |                    |                    |
    | ⑤ログイン情報      |                    |
    |---------------------------------------->|
    |                    |                    |
    |                         ⑥認証トークン生成
    |                    |                    |
    | ⑦認証応答メッセージ（リダイレクト）   |
    |<----------------------------------------|
    |                    |                    |
    | ⑧認証応答メッセージをメタCに送信      |
    |------------------->|                    |
    |                    |                    |
    |              ⑨トークン検証              |
    |                    |                    |
    | ⑩ログイン成功     |                    |
    |<-------------------|                    |

「複雑…」

「大丈夫。ポイントは、Googleでログインしたら、メタCが信用するってこと」

📋 SAMLアサーション

「SAMLで送られる情報をアサーションって言うんだ」

SAMLアサーションの中身:

xml

<saml:Assertion>
  <saml:Subject>
    <saml:NameID>shinya_yamamoto@gmail.com</saml:NameID>
  </saml:Subject>
  
  <saml:AttributeStatement>
    <saml:Attribute Name="email">
      <saml:AttributeValue>shinya_yamamoto@gmail.com</saml:AttributeValue>
    </saml:Attribute>
    
    <saml:Attribute Name="name">
      <saml:AttributeValue>山本慎也</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
  
  <saml:AuthnStatement>
    <saml:AuthnInstant>2024-01-02T23:00:00Z</saml:AuthnInstant>
  </saml:AuthnStatement>
  
  <ds:Signature>
    <!-- Googleのデジタル署名 -->
  </ds:Signature>
</saml:Assertion>

「この情報がGoogleからメタCに送られるんだ」

「デジタル署名もついてるから、改ざんされてないことが分かるね」

「正解！グループ1で勉強した知識がここで活きるでしょ」

第5章：OAuth 2.0

🔑 認証と認可の違い

「ねえ、里美。OAuthって何？SAMLと違うの？」

「いい質問！実は、目的が違うんだ」

認証（Authentication）vs 認可（Authorization）:

認証（Authentication）:

「あなたは誰？」を確認
本人確認
例：パスワード、指紋認証

認可（Authorization）:

「あなたは何ができる？」を許可
権限の付与
例：ファイルへのアクセス権、管理者権限

例え話:

【レンタカーを借りる】

①認証: 運転免許証を見せる
   → 「あなたは誰？運転できる人？」

②認可: レンタカー会社が車の鍵を渡す
   → 「この車を運転していいよ」

「SAMLは認証がメイン。OAuth 2.0は認可がメインなんだ」

🎫 OAuth 2.0とは

OAuth 2.0（オーオースツーポイントゼロ）とは:

正式名称: Open Authorization 2.0

一言で言うと: 権限の認可を行うためのプロトコル

使用例: 「TwitterアプリがGoogleドライブにアクセスしてもいいですか？」 → ユーザーが許可すると、TwitterアプリがGoogleドライブを操作できる

特徴:

アクセストークンを発行
パスワードを教えずに権限だけ渡す
RFC 6749で標準化

🔑 OAuth 2.0の登場人物

「OAuth 2.0には、4つの役割があるんだ」

①リソースオーナー（Resource Owner）

ユーザー本人
データの持ち主

②クライアント（Client）

サービスを使いたいアプリ
例：Twitterアプリ

③認可サーバー（Authorization Server）

権限を許可する
トークンを発行
例：Google

④リソースサーバー（Resource Server）

データを保存してる
例：Googleドライブ

例え話:

【友達に家の鍵を預ける】

①リソースオーナー: あなた（家の持ち主）
②クライアント: 友達
③認可サーバー: あなた（鍵を渡す人）
④リソースサーバー: 家（実際の資源）

友達が「家に入りたい」と言ったら、
あなたが許可して鍵を渡す。
でも、家の権利書は渡さない。

🔄 OAuth 2.0の流れ

里見が図を描く。

認可コードフロー（Authorization Code Flow）:

【ユーザー】  【アプリ】  【認可サーバー】  【リソースサーバー】
    |           |             |                  |
    | ①アプリ使いたい         |                  |
    |---------->|             |                  |
    |           |             |                  |
    |  ②認可要求（リダイレクト）                |
    |<----------|             |                  |
    |           |             |                  |
    | ③認可画面表示           |                  |
    |------------------------>|                  |
    |           |             |                  |
    | ④ログイン＋許可         |                  |
    |------------------------>|                  |
    |           |             |                  |
    |       ⑤認可コード       |                  |
    |<------------------------|                  |
    |           |             |                  |
    | ⑥認可コード            |                  |
    |---------->|             |                  |
    |           |             |                  |
    |      ⑦認可コードでトークン要求            |
    |           |------------>|                  |
    |           |             |                  |
    |           |  ⑧アクセストークン            |
    |           |<------------|                  |
    |           |             |                  |
    |      ⑨アクセストークンでデータ要求        |
    |           |-------------------------------->|
    |           |             |                  |
    |           |               ⑩データ          |
    |           |<--------------------------------|
    |           |             |                  |
    | ⑪データ表示            |                  |
    |<----------|             |                  |

「長い…」

「大丈夫。要点は3つだけ」

ポイント:

認可コードを発行（短命、1回きり）
認可コードでアクセストークンを取得
アクセストークンでリソースにアクセス

🎫 アクセストークン

アクセストークン（Access Token）とは:

一言で言うと: リソースにアクセスするためのチケット

特徴:

有効期限がある（通常1時間）
権限範囲（スコープ）が決まってる
使い捨て（期限切れたら再取得）

例え話:

映画館の入場券

- 有効期限: 今日の14:30の回のみ
- 権限: この映画を見られる（他の映画はダメ）
- 使い捨て: 次の映画を見るには新しいチケット

🔄 OAuth 2.0の4つのフロー

「OAuth 2.0には、用途に応じて4つのフローがあるんだ」

①認可コードフロー（Authorization Code Flow）

最も安全
サーバー側のアプリ向け
2段階（認可コード→トークン）

②Implicitフロー（インプリシットフロー）

認可コードを使わず、直接トークン
JavaScriptアプリ向け（非推奨になりつつある）

③リソースオーナーパスワードクレデンシャルズフロー

ユーザー名・パスワードを直接送る
信頼できるアプリのみ

④クライアントクレデンシャルズフロー

ユーザー不在
サーバー間通信

「普通は①の認可コードフローを使うよ」

🔐 スコープ（Scope）

「アクセストークンにはスコープがついてるんだ」

スコープとは:

一言で言うと: トークンでできることの範囲

例:

Googleドライブの例:

scope=drive.readonly
→ ファイルの読み取りのみ

scope=drive.file
→ アプリが作成したファイルのみ

scope=drive
→ 全ファイルにアクセス可能

「必要最小限のスコープだけ要求するのがベストプラクティスだよ」

第6章：OpenID Connect

🆔 OAuthの弱点

「ねえ、里美。OAuthで認証もできるんじゃない？」

「実は、それがOAuthのよくある誤解なんだ」

「え？」

「OAuth 2.0は認可のプロトコル。認証には向いてないの」

OAuth 2.0の問題点:

ユーザー情報の標準がない
- どうやってユーザー情報を取得する？
- 各サービスでバラバラ
トークンの検証方法が不明確
- アクセストークンは誰向け？
- 有効期限は？
セキュリティの穴
- トークンのすり替え攻撃が可能

「だから、OpenID Connectが生まれたんだ」

🔑 OpenID Connect（OIDC）とは

OpenID Connect（オープンアイディーコネクト）とは:

一言で言うと: OAuth 2.0の上に認証を追加したプロトコル

正式名称: OpenID Connect 1.0

特徴:

OAuth 2.0のフローをそのまま使う
IDトークンを追加
ユーザー情報の取得方法を標準化

バージョン: OpenID Connect 1.0（2014年）

🎫 IDトークン

「OpenID Connectの核心はIDトークンだよ」

IDトークン（ID Token）とは:

一言で言うと: ユーザー情報を含むデジタル署名付きトークン

形式: JWT（JSON Web Token）

中身:json

{
  "iss": "https://accounts.google.com",
  "sub": "110169484474386276334",
  "aud": "metac-app-12345",
  "exp": 1704236400,
  "iat": 1704232800,
  "name": "山本慎也",
  "email": "shinya_yamamoto@gmail.com",
  "picture": "https://...profile.jpg"
}

フィールド説明:

iss: 発行者（Googleなど）
sub: ユーザーID（一意の識別子）
aud: 対象アプリ
exp: 有効期限
iat: 発行時刻
name: 名前
email: メールアドレス

「これにデジタル署名がついてるから、改ざんできないんだ」

🔄 OpenID Connectのフロー

【ユーザー】  【アプリ】  【OpenIDプロバイダ】
    |           |             |
    | ①ログイン要求           |
    |---------->|             |
    |           |             |
    |  ②認証要求（scope=openid）
    |<----------|------------>|
    |           |             |
    | ③ログイン              |
    |------------------------>|
    |           |             |
    |  ④認可コード            |
    |<------------------------|
    |           |             |
    | ⑤認可コード            |
    |---------->|             |
    |           |             |
    |      ⑥認可コードでトークン要求
    |           |------------>|
    |           |             |
    |      ⑦IDトークン + アクセストークン
    |           |<------------|
    |           |             |
    | ⑧ログイン成功          |
    |<----------|             |

ポイント:

scope=openid を指定すると、IDトークンがもらえる
アクセストークンとIDトークンの両方が返る

📊 OAuth 2.0 vs OpenID Connect

里見が比較表を作る。

項目	OAuth 2.0	OpenID Connect
目的	認可	認証 + 認可
トークン	アクセストークン	IDトークン + アクセストークン
ユーザー情報	標準なし	標準化
署名	なし	IDトークンに署名
用途	API アクセス	ログイン
例	TwitterがGoogleドライブにアクセス	Googleアカウントでログイン

「OpenID ConnectはOAuth 2.0の拡張版って理解でOK」

第7章：FIDO（パスワードレス認証）

😫 パスワードの終焉

「ねえ、里美。結局、パスワードって完璧じゃないよね」

「その通り。だからパスワードを使わない認証が注目されてるんだ」

「それがFIDO？」

「正解！」

FIDO（ファイド）とは:

正式名称: Fast IDentity Online（素早いオンライン認証）

一言で言うと: パスワードを使わない認証の標準規格

策定: FIDO Alliance（Google、Microsoft、Appleなど）

特徴:

パスワード不要
フィッシング耐性
生体認証対応

🔐 FIDOの3つの仕様

「FIDOには3つのバージョンがあるんだ」

①FIDO UAF（ユーエーエフ）

Universal Authentication Framework
パスワード完全不要
生体認証のみ

②FIDO U2F（ユーツーエフ）

Universal 2nd Factor
パスワード + セキュリティキー
2段階認証の強化

③FIDO2（ファイドツー）

UAFとU2Fを統合
最新版
WebAuthnを含む

「今はFIDO2が主流だよ」

🔑 FIDO UAF

FIDO UAF（ユーエーエフ）とは:

正式名称: Universal Authentication Framework

一言で言うと: パスワードなしで認証

仕組み:

【登録時】
1. スマホで指紋登録
2. 秘密鍵・公開鍵を生成
3. 公開鍵だけサーバーに送る
4. 秘密鍵はスマホに保存（外に出ない）

【ログイン時】
1. サーバーからチャレンジ（乱数）
2. 指紋認証
3. 秘密鍵で署名
4. 署名をサーバーに送る
5. 公開鍵で検証
6. OK！

例え話:

指紋認証付き金庫

- 登録: 自分の指紋を登録
- 開ける: 指紋をタッチするだけ
- パスワード不要

メリット:

パスワード忘れない
フィッシングされない（秘密鍵が外に出ない）

デメリット:

デバイスが壊れたら困る（バックアップ必要）

🔐 FIDO U2F

FIDO U2F（ユーツーエフ）とは:

正式名称: Universal 2nd Factor

一言で言うと: 2段階認証をセキュリティキーで

仕組み:

【ログイン】
1. パスワード入力
2. セキュリティキーを挿す（またはタッチ）
3. ログイン成功

セキュリティキーの例:

YubiKey
Google Titan Security Key
USBキー

例え話:

銀行のカード + 暗証番号

①カードを挿す（第1要素）
②暗証番号を入力（第2要素）
③OK

メリット:

フィッシング耐性（物理キーが必要）
簡単（タッチするだけ）

デメリット:

キーを持ち歩く必要がある
キーを失くしたら困る

🌐 FIDO2 + WebAuthn

FIDO2（ファイドツー）とは:

一言で言うと: FIDO UAFとU2Fを統合した最新版

構成要素:

CTAP（シータップ）: デバイスとブラウザの通信プロトコル
WebAuthn: ブラウザのAPI

WebAuthn（ウェブオースン）とは:

正式名称: Web Authentication API

一言で言うと: ブラウザで使えるFIDO2のAPI

対応ブラウザ:

Chrome
Firefox
Safari
Edge

使える認証方法:

指紋認証
顔認証（Face ID）
セキュリティキー
Windows Hello

🔄 WebAuthnの流れ

【登録（Registration）】
1. ユーザー：「登録したい」
2. サーバー：チャレンジを送る
3. ブラウザ：「指紋を置いてください」
4. ユーザー：指紋タッチ
5. デバイス：秘密鍵・公開鍵を生成
6. ブラウザ：公開鍵をサーバーに送る
7. サーバー：公開鍵を保存

【認証（Authentication）】
1. ユーザー：「ログインしたい」
2. サーバー：チャレンジを送る
3. ブラウザ：「指紋を置いてください」
4. ユーザー：指紋タッチ
5. デバイス：秘密鍵で署名
6. ブラウザ：署名をサーバーに送る
7. サーバー：公開鍵で検証
8. OK！

ポイント:

パスワード一切不要
秘密鍵はデバイスから絶対に出ない
フィッシング不可能

第8章：結城の新たな攻撃

🎭 認証を突破する計画

【ある夜】

結城は、メタCがセキュリティを強化したことを知った。

「くっ…暗号化されて会話が見えなくなった」

モニターには、意味不明な暗号文だけが表示されている。

U2FsdGVkX1+vupppZksvRf5pq5g5XjFRlipRkwB0K1Y96Qsv2Lm+31cmzaAILwytX/...

「じゃあ、直接ログインすればいい」

結城は、慎也のアカウントを乗っ取る計画を立てた。

🎣 フィッシング攻撃

【作戦1: フィッシングメール】

結城は、偽のメタC運営を装ったメールを送った。

件名: 【重要】セキュリティアップデートのお知らせ

山本慎也様

メタC運営チームです。

最近、不正アクセスが増加しているため、
セキュリティアップデートを実施します。

以下のリンクから、パスワードの再設定をお願いします。
https://meta-c-security-update.fake.com

※48時間以内に対応いただけない場合、
　アカウントが一時停止される可能性があります。

メタC運営チーム

慎也は、怪しいと思いながらもリンクをクリックしかけた。

しかし、里見が止めた。

「待って！このURL、公式じゃないよ！」

「え？」

「見て。公式は meta-c.com だけど、これは meta-c-security-update.fake.com」

「本当だ…」

「フィッシング詐欺だよ。絶対にパスワード入力しちゃダメ」

結城の第1の作戦は失敗した。

📱 SMSフィッシング（スミッシング）

【作戦2: SMS攻撃】

【SMS】
メタCです。
不正ログインを検知しました。
以下から確認してください。
https://bit.ly/xxxxx

慎也は、今度は警戒した。

「里美、またフィッシングかな？」

「そうだね。公式はSMSでURLを送らないよ」

「よし、無視する」

結城の第2の作戦も失敗。

🔑 セキュリティキーの導入

「慎也、そろそろFIDO2のセキュリティキーを導入しよう」

「え、それって？」

里見がUSBサイズの小さなキーを取り出す。

「これがYubiKey。物理的なセキュリティキーだよ」

「これで何ができるの？」

「2段階認証が超強力になるんだ」

YubiKeyの設定:

【メタCの設定画面】

1. セキュリティ設定 → 2段階認証
2. 「セキュリティキーを追加」をクリック
3. YubiKeyをUSBポートに挿す
4. 「キーをタッチしてください」
5. YubiKeyのボタンを押す
6. 登録完了！

「これで、ログイン時にYubiKeyが必要になるんだ」

ログイン時:

1. ユーザー名・パスワード入力
2. 「YubiKeyをタッチしてください」
3. YubiKeyを挿してボタンを押す
4. ログイン成功！

「すごい！これならフィッシングされても安全？」

「そう！だって、物理的にキーがないとログインできないから」

😤 結城の挫折

同じ頃、結城は全ての攻撃が失敗したことに気づいていた。

「パスワードを盗んでも、キーがないとログインできない…」

「暗号化で会話も見えない…」

「もう、どうすればいいの…」

結城は、技術的な攻撃の限界を感じ始めていた。

第9章：守られた二人

💑 安心できるコミュニケーション

「里美、ありがとう」

「ん？」

「セキュリティのこと、いろいろ教えてくれて」

慎也が笑顔で言う。

「これで安心して、二人の時間を楽しめるよ」

「ふふ、どういたしまして」

里見も微笑む。

🛡️ メタCの進化

佐藤が、メタCのセキュリティ強化について報告する。

「山本さん、里見さんのおかげで、メタC全体のセキュリティが向上しました」

導入した技術:

TLS 1.3: 通信の暗号化
OpenID Connect: Googleアカウントでログイン
FIDO2対応: パスワードレス認証
多要素認証（MFA）: セキュリティキー対応
異常検知システム: 不正ログインを自動検知

「ユーザーからの評価も上々です」

📊 認証の多層防御

里見が図を描く。

【メタCの認証システム】

第1層: パスワード
  ↓
第2層: 2段階認証（SMS、アプリ、セキュリティキー）
  ↓
第3層: デバイス認証（信頼済みデバイス）
  ↓
第4層: 行動分析（ログイン時間、場所の異常検知）
  ↓
第5層: リスクベース認証（疑わしい時だけ追加認証）

「全部クリアして、初めてログインできるんだ」

「すごい…」

「一つ破られても、他の層で守る。これが多層防御だよ」

エピローグ：認証の未来

🌟 6ヶ月後

慎也は、情報処理安全確保支援士の試験に合格し、メタCのセキュリティチームに正式加入していた。

「佐藤さん、次のプロジェクトは何ですか？」

「パスワードレス認証の全面展開だよ」

「FIDO2ですね！」

「そう。将来的には、全ユーザーがパスワードなしでログインできるようにしたい」

🔐 パスワードのない世界

里見が語る。

「パスワードって、実は20世紀の遺物なんだよね」

「え？」

「1960年代に生まれた技術。もう60年以上前だよ」

「確かに…」

「21世紀は、生体認証とFIDOの時代。パスワードは過去のものになる」

慎也が頷く。

「そんな世界を、僕たちが作るんだね」

「そう。安全で、便利で、誰もが使える認証システム」

💝 安心できる未来

メタCの美しいワールドで、慎也と里見は寄り添っていた。

「ねえ、慎也」

「なあに？」

「認証技術って、信頼を守る技術なんだね」

「え？」

「本人だと証明する。それって、相手を信頼するってことでしょ」

「…そうだね」

慎也が里見を抱きしめる。

「里美のこと、ずっと信頼してるよ」

「私も」

二人の愛は、最新の認証技術で守られている。

そして、その技術は、二人の信頼関係を象徴していた。

🎓 用語まとめ

認証基礎

用語	読み	意味
AAA	トリプルエー	Authentication（認証）、Authorization（認可）、Accounting（記録）の3要素
認証	にんしょう	「あなたは誰？」を確認すること
認可	にんか	「あなたは何ができる？」を決定すること
アカウンティング	–	「あなたは何をした？」を記録すること
チャレンジレスポンス	–	パスワードを直接送らずに本人確認する方法
多要素認証	たようそにんしょう	複数の要素（知識・所持・生体）で認証
MFA	エムエフエー	Multi-Factor Authentication（多要素認証）

SSO（シングルサインオン）

用語	読み	意味
SSO	エスエスオー	Single Sign-On。1回のログインで複数サービスを利用
エージェント型	–	各サーバーにエージェントを配置するSSO方式
リバースプロキシ型	–	入り口で一括認証してから転送するSSO方式
Kerberos	ケルベロス	チケットを使ったエージェント型SSOの代表例
チケット	–	認証済みを証明する一時的な証明書

アイデンティティ連携

用語	読み	意味
アイデンティティ連携	–	複数サービス間で認証情報を共有する仕組み
IdP	アイディーピー	Identity Provider。認証を提供する側
SP	エスピー	Service Provider。認証を利用する側
SAML	サムル	Security Assertion Markup Language。IdPとSP間の情報交換プロトコル
SAML 2.0	サムルツーポイントゼロ	SAMLの現行バージョン
アサーション	–	SAMLで送られる認証情報

OAuth 2.0

用語	読み	意味
OAuth 2.0	オーオースツーポイントゼロ	認可のためのプロトコル
リソースオーナー	–	データの所有者（ユーザー）
クライアント	–	サービスを使いたいアプリ
認可サーバー	にんかさーばー	権限を許可してトークンを発行
リソースサーバー	–	実際のデータを保存しているサーバー
認可コード	にんかこーど	アクセストークンを取得するための一時コード
アクセストークン	–	リソースにアクセスするためのチケット
スコープ	–	トークンの権限範囲
認可コードフロー	にんかこーどふろー	OAuth 2.0の標準的なフロー（最も安全）
Implicitフロー	インプリシットふろー	認可コードを経由しないフロー（非推奨）
リフレッシュトークン	–	アクセストークンを再取得するためのトークン

OpenID Connect

用語	読み	意味
OpenID Connect	オープンアイディーコネクト	OAuth 2.0に認証機能を追加したプロトコル
OIDC	オーアイディーシー	OpenID Connectの略称
IDトークン	アイディートークン	ユーザー情報を含むデジタル署名付きトークン
JWT	ジェイダブリューティー	JSON Web Token。IDトークンの形式
UserInfo エンドポイント	–	ユーザー情報を取得するAPI

FIDO

用語	読み	意味
FIDO	ファイド	Fast IDentity Online。パスワードレス認証の標準
FIDO Alliance	ファイドアライアンス	FIDO規格を策定する業界団体
FIDO UAF	ユーエーエフ	Universal Authentication Framework。完全パスワードレス
FIDO U2F	ユーツーエフ	Universal 2nd Factor。2段階認証強化
FIDO2	ファイドツー	UAFとU2Fを統合した最新版
WebAuthn	ウェブオースン	Web Authentication API。ブラウザで使えるFIDO2 API
CTAP	シータップ	Client to Authenticator Protocol
セキュリティキー	–	物理的な認証デバイス（YubiKeyなど）
YubiKey	ユビキー	代表的なセキュリティキーの製品名
パスワードレス認証	–	パスワードを使わない認証方式

その他

用語	読み	意味
フィッシング	–	偽サイトでパスワードを盗む詐欺
スミッシング	–	SMSを使ったフィッシング詐欺
リスクベース認証	–	疑わしい時だけ追加認証を要求
デバイスフィンガープリント	–	デバイスの特徴で識別
行動分析	こうどうぶんせき	ユーザーの行動パターンから異常を検知
CAPTCHA	キャプチャ	人間とボットを区別するテスト

📚 次のステップ

この物語で、認証とシングルサインオンの基礎を学びました。

復習のポイント:

AAAフレームワーク: 認証・認可・記録の3要素
SSO: 1回のログインで複数サービス
SAML: 企業向けアイデンティティ連携
OAuth 2.0: 認可プロトコル
OpenID Connect: 認証 + 認可
FIDO2: パスワードレス認証の未来

前の記事

2026年1月3日
メタCセキュリティ物語～暗号化とデジタル署名編～
次の記事

2026年1月6日
メタCセキュリティ物語～アクセス制御技術編～

メタCセキュリティ物語〜認証とシングルサインオン編〜

プロローグ：パスワードの限界

🔐 パスワード管理の悪夢

📝 パスワードメモの危険

💑 里美の優しい提案

第1章：AAAフレームワーク

🔑 認証・認可・アカウンティング

🎭 具体例で理解

🔐 メタCでのAAA

第2章：チャレンジレスポンス認証

🎯 パスワードを送らない認証

🎲 例え話

🔒 HMACとの組み合わせ

第3章：シングルサインオン（SSO）

😫 パスワード地獄からの解放

🎫 SSOの2つのタイプ

🎟️ エージェント型SSO（Kerberos）

🚪 リバースプロキシ型SSO

⚖️ エージェント型 vs リバースプロキシ型

第4章：SAML（アイデンティティ連携）

🌐 外部サービスとの連携

🔑 IdPとSP

📨 SAML（サムル）

🔄 SAMLの流れ

📋 SAMLアサーション

第5章：OAuth 2.0

🔑 認証と認可の違い

🎫 OAuth 2.0とは

🔑 OAuth 2.0の登場人物

🔄 OAuth 2.0の流れ

🎫 アクセストークン

🔄 OAuth 2.0の4つのフロー

🔐 スコープ（Scope）

第6章：OpenID Connect

🆔 OAuthの弱点

🔑 OpenID Connect（OIDC）とは

🎫 IDトークン

🔄 OpenID Connectのフロー

📊 OAuth 2.0 vs OpenID Connect

第7章：FIDO（パスワードレス認証）

😫 パスワードの終焉

🔐 FIDOの3つの仕様

🔑 FIDO UAF

🔐 FIDO U2F

🌐 FIDO2 + WebAuthn

🔄 WebAuthnの流れ

第8章：結城の新たな攻撃

🎭 認証を突破する計画

🎣 フィッシング攻撃

📱 SMSフィッシング（スミッシング）

🔑 セキュリティキーの導入

😤 結城の挫折

第9章：守られた二人

💑 安心できるコミュニケーション

🛡️ メタCの進化

📊 認証の多層防御

エピローグ：認証の未来

🌟 6ヶ月後

🔐 パスワードのない世界

💝 安心できる未来

🎓 用語まとめ

認証基礎

SSO（シングルサインオン）

アイデンティティ連携

OAuth 2.0

OpenID Connect

FIDO

その他

📚 次のステップ

メタCセキュリティ物語～暗号化とデジタル署名編～

メタCセキュリティ物語 ～アクセス制御技術編～

メタCセキュリティ物語～アクセス制御技術編～