モダンWeb認証入門

モダンWeb認証入門

パスワードからOAuth、そしてパスワードレスの未来へ

データサイエンスAI実践（2025年度版）

Transcript

1. モダンWeb 認証入門 パスワードからOAuth 、そしてパスワードレスの未来へ 1
2. はじめに：ログインボタンの裏にある「魔法」 日常的に使う「Googleでログイン」や指紋認証。 一見すると単純な操作ですが、その裏側には、私たちのデジタルアイデンティティ を守るための洗練された技術が隠されています。 このプレゼンテーションでは、その「魔法」の正体を解き明かします。 2
3. このプレゼンテーションで解き明かす疑問 1. Web サイトはどうやって「あなた」を認識するのか？ (認証の基本) 2. パスワードを教えずに、他のアプリのデータをどうやって安全に使うのか？ (権限の委任) 3. なぜ世界はパスワードから離れつつあるのか？ (パスワードレスの未来) 3
4. 全体の流れ 1. 基礎の理解 認証(Authentication)と認可(Authorization) 2. 過去の課題 パスワードが抱える根本的な問題 3. 現代の解決策 認可のための OAuth 2.0 認証のための OpenID Connect 4. 未来への展望 パスワードレスを実現する WebAuthn と パスキー 4
5. 第1 章 アクセスの2 つの柱： 認証 と 認可 5
6. 認証 (Authentication / AuthN) 『あなたは誰ですか？』 ユーザーが主張する通りの 本人であるかを確認するプロセスです。 例えるなら、建物の玄関で行われる 身元確認です。 6
7. 認証の3 要素 認証は、これらの要素の組み合わせで行われます。 知識情報 (Something you know) パスワード、PINコード、秘密の質問 所持情報 (Something you have) ワンタイムパスワード、物理セキュリティキー 生体情報 (Something you are) 指紋、顔、虹彩 7
8. 認可 (Authorization / AuthZ) 『あなたは何をする権限がありますか？』 認証が成功した後に行われるプロセスです。 認証されたユーザーが、システム内で どの操作を行い、どのデータにアクセスでき るかを決定します。 8
9. 例え話：空港にて 認証 (Authentication) チェックインカウンターで パスポートを提示し、本人確認をすること。 認可 (Authorization) 受け取った 搭乗券に記載された情報（搭乗ゲート、座席クラス、ラウンジ 利用可否など）。 あなたが空港内で「何をする権限があるか」を示します。 9
10. なぜこの区別が重要なのか？ 「関心の分離」 が現代のWebセキュリティの鍵です。 認証（本人確認）という重い責任 GoogleやFacebookのような信頼できる専門家（IDプロバイダー）に任せ る。 認可（限定的な権限の付与） 各アプリケーションが必要な分だけを管理する。 この分離のおかげで、安全で柔軟なシステム設計が可能になります。 10
11. 認証 vs 認可 まとめ 特徴 認証 (Authentication) 認可 (Authorization) 答える問い 「あなたは誰ですか？」 「あなたは何をする権限がありま すか？」 主な目的 本人確認 権限付与 プロセスの例 ユーザー名とパスワードの 入力 ログイン後に特定のファイルへア クセス 例え話 空港でパスポートを提示 搭乗券でVIPラウンジに入る HTTP ステー タス 401 Unauthorized (認証失 敗) 403 Forbidden (権限なし) 11
12. 第2 章 パスワードの時代： 欠陥のある基盤 12
13. パスワード認証の根本的な欠陥 「共有された秘密 (Shared Secret) 」 パスワード認証の根本的な問題は、 ユーザーとサーバーの両方が同じ「秘密の情 報」を知っている必要がある点にあります。 この構造が、様々な攻撃の温床となります。 13
14. パスワードが抱える問題点 ( ユーザー側) 弱く、使い回されるパスワード 多くのユーザーが、記憶しやすい単純なパスワードを設定しがちです。 複数のサービスで同じパスワードを使い回すと、一つの漏洩が他のサービ スにも被害を広げます ( ドミノ倒しリスク)。 フィッシングとソーシャルエンジニアリング 偽サイトに騙されて認証情報を入力してしまうと、簡単になりすまされま す。 14
15. パスワードが抱える問題点 ( サーバー側) データ侵害とクレデンシャルスタッフィング サーバーが攻撃されデータベースが流出すると、パスワード情報が盗まれ る可能性があります。 攻撃者はそのリストを使い、他のサービスで自動的にログインを試みます ( クレデンシャルスタッフィング攻撃)。 15
16. 応急処置としての解決策 パスワードの問題を軽減するため、いくつかの対策が生まれました。 多要素認証 (MFA) パスワードに加えて、スマホのコードや指紋などを要求することで、セキ ュリティを大幅に向上させます。 パスワードマネージャー サービスごとに複雑でユニークなパスワードを自動生成・管理し、使い回 しを防ぎます。 しかし、これらも根本的な解決には至りません。 16
17. 根本的なジレンマ：セキュリティ vs ユーザビリティ セキュリティを強化すると... パスワードを複雑にする、MFAを導入する 利便性 ( ユーザビリティ) は低下する... パスワードを覚えられない、ログインが面倒になる このトレードオフを解消するため、業界は パスワードに代わる新しいパラダイムを 模索し始めました。 17
18. 第3 章 委任のジレンマ： 認可のためのOAuth 2.0 登場 18
19. 新たな課題：権限の委任 シナリオ: オンラインの写真印刷サービスが、あなたのGoogle フォトにある写真を読み込ん で印刷したい。 どうやって許可しますか？ Googleのパスワードを印刷サービスに教えるのは 絶対にNGです。 Gmailやドライブなど、 全ての権限を渡してしまうことになります。 19
20. 解決策：OAuth 2.0 インターネットの「バレーキー」 OAuth 2.0は、 「委任された認可 (Delegated Authorization) 」 の問題を解決する 標準プロトコルです。 重要: OAuth 2.0は 認可のためのプロトコルであり、 認証のためではありません。 車のバレーキーのように、 限定的で一時的な権限だけを第三者アプリに安全に渡す 仕組みです。 20
21. OAuth 2.0 の登場人物 (4 つの役割) 1. リソースオーナー データの所有者 (例: あなた) 2. クライアント データにアクセスしたいアプリ (例: 写真印刷サービス) 3. 認可サーバー 権限を許可し、トークンを発行する (例: Google) 4. リソースサーバー データが保管されている場所 (例: Google フォトのAPI) 21
22. 代表的なフロー：認可コードフロー 一見複雑ですが、 セキュリティを最大限に高めるための設計です。 22
23. 認可コードフローの流れ ( 前半) 1. ユーザー操作: ユーザーが写真印刷サービスで「Googleフォトと連携」をクリック。 2. リダイレクト: ブラウザがGoogleの認可サーバーへ移動。 3. ユーザーの同意: Googleにログインし、「このアプリに写真へのアクセスを許可します か？」という画面で「許可」をクリック。 4. 認可コードの発行: Googleは、一時的な 認可コードを付けてブラウザを写真印刷サービスへ戻 す。 23
24. 認可コードフローの流れ ( 後半) 5. コードとトークンの交換 ( サーバー間通信): 写真印刷サービスの サーバーが、受け取った認可コードを使って裏側で Googleにリクエスト。 6. アクセストークンの取得: Googleはコードを検証し、正式な アクセストークンを写真印刷サービスの サーバーに渡す。 7. リソースへのアクセス: 写真印刷サービスは、そのアクセストークンを使ってGoogleフォトにアク セスし、写真を読み込む。 24
25. なぜこんなに複雑なのか？ アクセストークンという強力な鍵を、安全性の低いブラウザ（フロントチャネル） に直接渡さないためです。 フロントチャネル ( ブラウザ経由) 一時的で一度しか使えない 認可コードだけを渡す。 バックチャネル ( サーバー間通信) 安全な通信路で、本物の アクセストークンを交換する。 この設計が、トークン漏洩のリスクを最小限に抑えます。 25
26. OAuth の重要用語 スコープ (Scope) クライアントが要求する権限の範囲。「写真の読み取り専用」のように、 必要最小限の権限を指定します。 アクセストークン (Access Token) リソースサーバーへのアクセス権を示す「チケット」。通常、有効期限は 短い（例: 1時間）。 リフレッシュトークン (Refresh Token) アクセストークンが切れた際に、新しいアクセストークンを再取得するた めの、より有効期限の長いトークン。 26
27. 第4 章 認可から本人確認へ： OpenID Connect (OIDC) 27
28. OAuth だけでは足りなかったピース 「Googleアカウントでログイン」機能。 多くの人がこれをOAuthの機能だと考えていますが、実は違います。 OAuth 2.0 自体には、ログインしたユーザーが「誰なのか」を標準的な方法で伝え る機能がありません。 OAuthが渡すのは、あくまでリソースにアクセスするための アクセストークンで す。 28
29. 解決策：OpenID Connect (OIDC) OAuth 2.0 上のアイデンティティレイヤー OpenID Connect (OIDC)は、OAuth 2.0プロトコルの上に作られた薄いレイヤーで す。 その 唯一の目的は「認証」、つまりクライアントがユーザーの本人確認を行うこと です。 29
30. OIDC の仕組み OIDCのフローは、OAuthの認可コードフローとほぼ同じです。 しかし、決定的に重要な追加点が2つあります。 1. リクエスト時に scope パラメータに openid という値を追加する。 2. レスポンスとして、アクセストークンに加えてID トークンという新しいトーク ンが返される。 30
31. OIDC の核心：ID トークン (JWT) ID トークンは、ユーザーが確かに認証されたという事実を証明する**「検証可能な デジタル身分証明書」**です。 これは JSON Web Token (JWT) という標準形式で表現されます。 31
32. JWT の構造 JWTは . で区切られた3つの部分から構成されます。 1. ヘッダー (Header) 署名アルゴリズムなどのメタ情報。 2. ペイロード (Payload) ユーザーID、発行者、有効期限などの情報（クレーム）。 3. 署名 (Signature) ヘッダーとペイロードを、IDプロバイダーの 秘密鍵で電子署名したもの。 この署名があるおかげで、受け取った側はID プロバイダーの公開鍵を使って、トー クンが本物で改ざんされていないことを検証できます。 32
33. OAuth 2.0 vs OpenID Connect 項目 OAuth 2.0 OpenID Connect (OIDC) 主な目的 認可 (Authorization) 認証 (Authentication) 答える問い 「このアプリは何ができます か？」 「このユーザーは誰ですか？」 ベース ベースとなるプロトコル OAuth 2.0上のレイヤー 主要なトー クン アクセストークン ID トークン (＋アクセストーク ン) ユースケー ス 「連絡先へのアクセスを許可」 「Google アカウントでログイ ン」 33
34. 第5 章 パスワードレスの未来： WebAuthn とパスキー 34
35. 残された最後の課題 OAuthとOIDCを使っても、最初のIDプロバイダー（Googleなど）へのログインに は、依然としてパスワードが使われています。 つまり、システムの根幹には**「共有された秘密」**という脆弱性が残ったままで す。 この根本問題を解決するのが WebAuthn (Web Authentication) です。 35
36. WebAuthn の基盤：公開鍵暗号方式 WebAuthnはパスワードの代わりに、実績のある 公開鍵暗号方式を利用します。 1. 鍵ペアの生成 デバイス上で「秘密鍵」と「公開鍵」のペアを生成。 2. 秘密鍵 (Private Key) デバイス内の安全な領域に保管され、決して外に出ない。 3. 公開鍵 (Public Key) サーバーに登録し、アカウントと紐付ける。サーバーが知っているのはこ の安全な公開鍵だけ。 サーバーは秘密鍵を一切知らないため、情報漏洩のリスクが根本的にありません。 36
37. WebAuthn のフロー ①：登録 (Registration) 1. ユーザーがサイトで「パスキーを作成」などをクリック。 2. サーバーがランダムなデータ（チャレンジ）をブラウザに送信。 3. ブラウザがデバイスの認証器（指紋センサー等）に鍵ペアの生成を要求。 4. ユーザーが指紋などで許可。 5. 新しい公開鍵がサーバーに送られ、アカウントに保存される。 37
38. WebAuthn のフロー ②：認証 (Authentication) 1. ユーザーがログインしようとする。 2. サーバーが新しい「チャレンジ」を送信。 3. ユーザーが指紋などで操作を承認。 4. デバイス内の 秘密鍵が「チャレンジ」に電子署名を行う。 5. サーバーは、登録済みの 公開鍵を使って署名を検証。 6. 検証が成功すれば、本人であると証明され、ログインが許可される。 38
39. パスキー (Passkeys) とは？ パスキーは、WebAuthnの仕組みをより使いやすくした ブランド名であり、 実装形 態です。 最大の特徴: WebAuthnで作成された認証情報（秘密鍵と公開鍵のペア）を、iCloud やGoogle パスワードマネージャーを介して、複数のデバイス間で安全に同期できる点です。 これにより、スマホで作ったパスキーを使ってPCからもシームレスにログインでき ます。 39
40. WebAuthn の最強の利点：フィッシング耐性 WebAuthnは、設計段階からフィッシング攻撃に耐性を持つように作られていま す。 オリジン・バインディング 認証情報は、生成されたサイトのドメイン（例: https://my-bank.com ） と暗号学的に強く結びつけられます。 攻撃者が巧妙な偽サイト（例: https://my-bank-login.com ）を作って も、ドメインが違うため認証は 自動的に失敗します。 フィッシングを見破る責任が、間違いを犯しやすい人間から、間違いを犯さないプ ロトコルに移されます。 40
41. 結論 現代デジタルアイデンティティの統合的理解 41
42. 本日のまとめ：各技術の役割 パスワード 共有された秘密という 根本的な課題を抱える。 OAuth 2.0 認可を担当。「あなたは何ができますか？」 OpenID Connect (OIDC) 認証を担当。「あなたは誰ですか？」 WebAuthn / パスキー パスワードレス認証を実現。「共有された秘密」を完全に排除。 42
43. 全体像：連携するエコシステム これらの技術は、互いに連携して機能するエコシステムを形成しています。 例: 1. ログインにはWebAuthn/ パスキー（認証）を利用。 2. ログイン後、Dropboxのファイルにアクセスする必要が生じたら、OAuth 2.0 （認可）を使って権限を要求する。 それぞれの技術が最も得意な領域で役割を分担することで、安全で便利なWebが実 現されています。 43
44. 最後に Web認証の進化の物語は、単なる技術の変遷ではありません。 インターネットをより安全に、そしてより人間にとって使いやすい場所にするため の、絶え間ない探求の物語です。 44
45. ご清聴ありがとうございました 45