認証・認可プロトコル論

Aug 4, 2025 10 min

概要

認証・認可プロトコルは、情報システムにおけるユーザーやサービスの身元確認と権限管理を担う。本章では、現代のWeb・クラウド環境で主流となる認証・認可技術の理論と実装について体系的に述べる。

1. 認証・認可の基本概念

  • 認証（Authentication）：ユーザやシステムが「誰であるか」を確認する行為。
  • 認可（Authorization）：認証された主体に対して「何ができるか」を制御する行為。
  • ID管理：ID、属性情報、認証情報の一元管理。IdP（Identity Provider）とSP（Service Provider）の分離が主流。

2. 認証方式の分類

認証方式説明備考
パスワード認証知識ベース。最も一般的であるが漏洩・総当たり攻撃に弱いパスワード管理・強度ポリシーが重要
多要素認証（MFA）知識（Something you know）+ 所持 + 生体の組合せ攻撃耐性が高く、標準化が進む（例：SMS+OTP）
生体認証指紋、顔、虹彩等誤認識率（FAR／FRR）への考慮が必要
ワンタイムパスワード（OTP）時間またはイベントベースで変化する一時的パスワードTOTP（時間）とHOTP（イベント）が主流

3. 認可方式の分類

制御方式概要適用例
RBACロールに基づいてアクセス権を付与組織階層型のシステム設計に有効
ABAC属性（ユーザー属性・環境属性など）に基づく柔軟性が高く、ポリシー管理が複雑になりがち
PBACビジネスルールに基づいた動的アクセス制御クラウド／API連携などで導入増加中

4. IDフェデレーション技術

🧭 はじめに

IDフェデレーションとは、異なるドメイン（企業、クラウドサービス、アプリ）間で認証情報を安全に共有し合う仕組みを指す。認証機能をIdP（Identity Provider）に集中させ、各種サービス（SP：Service Provider）側ではその結果のみを信頼することで、SSO（Single Sign-On）や認可委譲が実現される。

この枠組みを支える主要技術が SAML 2.0 / OAuth 2.0 / OpenID Connect (OIDC) である。これらは単なる認証プロトコルではなく、トークンの発行と検証、データフローと署名の設計、セキュリティの境界線の再定義といった複雑な構成要素を伴う。

🔗 1. SAML 2.0：XMLベースの企業間SSO標準

  • 用途：B2B環境でのSSO（例：社内ポータル → Salesforce）
  • 構成：IdP、SP、ユーザーの3者間通信
  • データ形式：XMLベースの「SAMLアサーション」

処理フロー概略：

  1. ユーザーがSPにアクセス
  2. SPがユーザーをIdPへリダイレクト（AuthnRequest）
  3. IdPが認証後、署名付きSAMLアサーションをSPへ返却
  4. SPは署名検証とアサーションの有効性を確認し、認証完了

脅威・脆弱性：

  • XML署名の不備 → SAML署名ラッピング攻撃
  • アサーションの使い回し → リプレイ攻撃
  • Clock skew、IDの未検証など → 認証バイパス

対策：

  • ライブラリの脆弱性回避（OpenSAMLなどの安全利用）
  • アサーションの一意性・有効期限・Audience制限の厳格検証
  • HTTPS強制、署名の整合性確認

🔑 2. OAuth 2.0：認可のフレームワーク

OAuthは、**「第三者アプリに自分のデータアクセスを許可する仕組み」**を定義した認可のフレームワーク。主にAPIアクセス制御に使用される。

主なロール：

  • Resource Owner（ユーザー）
  • Client（アプリ）
  • Authorization Server（認可サーバ）
  • Resource Server（API提供者）

代表的なグラントタイプ：

  • Authorization Code Flow：Webアプリで推奨。セキュア。
  • Implicit Flow（非推奨）：トークンがURLに露出。
  • Client Credentials：バックエンド連携用。
  • Device Code Flow：スマートTV等向け。

攻撃例：

  • リダイレクトURIの不備 → Open Redirect攻撃
  • トークン窃取 → CSRFまたはログ流出
  • スコープ過剰要求 → 権限昇格

🆔 3. OpenID Connect（OIDC）：認証も可能なOAuth拡張

OIDCはOAuth 2.0の上位互換として、IDトークン（JWT）を用いたユーザー認証を可能にしたプロトコル。

追加要素：

  • ID Token：ユーザー属性（sub, name, email等）を含むJWT
  • nonce：リプレイ攻撃防止のためのトークン固有ID
  • userinfoエンドポイント：ユーザー情報を取得

検証ポイント：

  • IDトークンの署名（alg: none攻撃を禁止）
  • nonceの検証
  • iss, aud, exp, iatのチェック

📌 試験・実務の要点

  • OAuthとOIDCの役割分担の違いを明確に理解（OAuth：認可／OIDC：認証）
  • フロー別の脅威モデルと対策（Authorization Code Flow推奨）
  • トークン（アクセストークン／IDトークン）の構造と検証項目
  • SAML/OIDC間の設計選択（B2B向けかSPA向けか）

5. 認証・認可プロトコルの実装例

  • SSO（Single Sign-On）
    • 一度の認証で複数サービスにアクセス可能。SAMLやOIDCにより実現。
  • OAuth連携によるAPIアクセス制御
    • アクセストークンのスコープ、有効期限、リフレッシュトークン等を設計に反映。
  • OIDCによるID連携
    • IDトークンの検証（署名アルゴリズム、nonce確認）などが必要。

6. セキュリティ課題と対策

📉 セッション管理の失敗 → Session Hijack／Fixation

  • 脅威：攻撃者が有効なセッショントークンを不正取得してログイン状態を乗っ取る
  • 対策：
    • Secure属性／HttpOnly属性／SameSite属性の設定
    • セッションIDは認証後に再生成
    • セッションタイムアウト（15分目安）

🔁 CSRF（クロスサイトリクエストフォージェリ）

  • 仕組み：ユーザーがログイン中に悪意あるサイトから勝手にリクエストが送信される
  • 対策：
    • CSRFトークンをフォームに埋め込み、検証
    • SameSite=LaxまたはStrictの設定（特にSPAは要注意）
    • Refererヘッダ／Originヘッダのチェック

🔓 認証情報の漏洩と盗用

  • 脆弱性要因：
    • パスワードの平文保存
    • パスワード再利用
    • 認証ログの露出
  • 対策：
    • ハッシュ＋ソルト（PBKDF2、bcrypt、Argon2）
    • MFA導入
    • ログ監査とアラート設定

🎫 トークンの不正利用（特にJWT）

  • 攻撃ベクトル：
    • alg: noneによる署名スキップ
    • 公開鍵と秘密鍵の誤配置
    • 長寿命トークンによるリプレイ攻撃
  • 設計対策：
    • JWTの署名アルゴリズムを固定化
    • exp（有効期限）＋jti（一意識別子）の確認
    • トークンのリフレッシュと失効機構の設計

🧠 パスワードリスト型攻撃（Credential Stuffing）

  • 特長：漏洩済みID/Passwordの再利用攻撃
  • 対策：
    • IP／User-Agentベースのアクセス制限
    • CAPTCHA、MFA
    • リスクベース認証（ログイン挙動のスコアリング）

📌 試験・実務の注目点

  • JWTの署名検証・トークン失効設計
  • セッションIDのスコープ管理（ドメイン/パス）
  • セキュアクッキーとCSRF防止策の連携
  • パスワードハッシュの推奨アルゴリズム
  • API経由の認証情報送信時のリスク（Basic認証、Token型など）

7. 最新動向

🔐 FIDO2／WebAuthn：パスワードレスの新標準

  • 背景：パスワードに依存した認証では、漏洩・再利用・フィッシングに限界
  • 仕組み：
    • 公開鍵暗号を使ったクライアント証明
    • 認証器（セキュリティキー／OS内蔵TPM等）が秘密鍵を保持
  • プロトコル構成：
    • FIDO2 = WebAuthn（API）+ CTAP2（認証器連携）

メリット：

  • 認証情報がサーバに保存されない（プライバシー保護）
  • フィッシング耐性が極めて高い

課題：

  • 対応ブラウザ／端末依存
  • 認証器の紛失対応（リカバリ問題）

🌐 IDaaS（Identity as a Service）

  • 内容：クラウド上でID管理・認証基盤を提供するサービス
  • 代表例：Azure AD、Okta、OneLogin
  • 特徴：
    • SAML／OIDC／SCIM連携による統合
    • 管理者不要な即時プロビジョニング（Just-In-Time）

導入メリット：

  • 内製開発不要、スケーラブル、障害耐性
  • SaaS連携前提のゼロトラスト設計に適合

🪪 DID／VC（分散型IDと検証可能資格情報）

  • 目的：中央集権的IdPを不要にし、**自己主権型ID（SSI）**を実現
  • 構成要素：
    • DID Document：公開鍵とメタ情報の宣言
    • VC（Verifiable Credential）：署名付き資格情報
    • Holder／Verifier／Issuerの三者構
  • 用途例：
    • 大学卒業証明、ライセンス、本人確認情報などの分散管理
    • EUのeIDAS規格との連携

📌 基礎知識チェック

設問 - Level 1

  1. 「認証」と「認可」の最も大きな違いを簡潔に説明してください。
  2. 多要素認証（MFA）が「知識」「所持」「生体」の何を組み合わせてセキュリティを強化するか、例を挙げて説明してください。
  3. 認可方式として「ロールに基づいてアクセス権を付与する」方式を何と呼びますか？
  4. IDフェデレーション技術の目的を簡潔に説明してください。
  5. SAML 2.0が主に利用される環境として適切なものを一つ挙げてください。
  6. OAuth 2.0における「Resource Owner」とは誰のことですか？
  7. OpenID Connect (OIDC) がOAuth 2.0に追加して実現する主要な機能は何ですか？
  8. セッション管理の失敗によって起こり得る攻撃の一つを挙げ、その対策の一つを簡潔に述べてください。
  9. CSRF攻撃の主な対策としてフォームに埋め込むべきものは何ですか？
  10. FIDO2/WebAuthnがパスワード認証と比較して優れている点の一つを挙げてください。

設問 - Level 2

  1. 認証方式において、パスワード認証の課題点と、それを補完する多要素認証（MFA）の具体的な利点を説明してください。
  2. SAML 2.0とOpenID Connect (OIDC) は、それぞれどのようなユースケースに特に適しているか、その理由とともに説明してください。
  3. OAuth 2.0の代表的なグラントタイプの一つである「Authorization Code Flow」がWebアプリケーションで推奨される理由を、セキュリティの観点から説明してください。
  4. JWT（JSON Web Token）をトークンとして利用する際に考慮すべきセキュリティ上の脅威と、その対策を具体的に2つ説明してください。
  5. IDaaS（Identity as a Service）が現代のクラウドサービスやSaaS連携において、どのようなメリットを提供するのか、具体例を挙げて説明してください。
  6. セッションハイジャックとCSRFは、いずれもセッションに関連する攻撃ですが、それぞれどのような仕組みで攻撃が成立し、どのような対策が有効か違いを明確にして説明してください。
  7. 「alg: none」攻撃とは何か、JWTの検証においてなぜこの攻撃を防ぐ必要があるのか説明してください。
  8. パスワードリスト型攻撃の仕組みを説明し、その対策としてMFAの他にどのような手法が考えられるか、2つ具体的に挙げてください。
  9. FIDO2/WebAuthnにおける「認証器（Authenticator）」の役割と、それがパスワードレス認証においてセキュリティをどのように向上させるか説明してください。
  10. 分散型ID（DID）と検証可能資格情報（VC）が目指す「自己主権型ID（SSI）」とはどのような概念か、中央集権型ID管理との違いを交えて説明してください。

回答 - Level 1

  1. 認証は「誰であるか」を確認する行為、認可は「何ができるか」を制御する行為。
  2. 知識（例：パスワード）、所持（例：スマートフォンに届くSMSコード）、生体（例：指紋認証）を組み合わせる。
  3. RBAC（ロールベースアクセス制御）。
  4. 異なるドメイン間で認証情報を安全に共有し、SSO（Single Sign-On）や認可委譲を実現すること。
  5. B2B環境でのSSO（例：企業内の異なるシステム間でのログイン）。
  6. サービスを利用したいエンドユーザー。
  7. IDトークン（JWT）を用いたユーザー認証。
  8. Session Hijack（セッションハイジャック）。対策：セッションIDの認証後の再生成。
  9. CSRFトークン。
  10. 認証情報がサーバに保存されない、フィッシング耐性が極めて高い。

回答 - Level 2

  1. パスワード認証の課題点: 漏洩、総当たり攻撃、パスワードの使い回しによる被害拡大などがある。MFAの利点: 知識（パスワード）が漏洩しても、所持物（スマホ）や生体情報がなければ認証が突破されにくいため、攻撃耐性が大幅に向上する。
  2. SAML 2.0: XMLベースで企業間の複雑な連携やレガシーシステムとの統合に適しており、主にB2B環境でのSSOに利用される。OIDC: OAuth 2.0をベースにしており、RESTful APIやSPA（Single Page Application）といったモダンなWeb・クラウドアプリケーションでの認証連携、特にエンドユーザー認証に強く、利便性と柔軟性が高い。
  3. 「Authorization Code Flow」は、認証コードを介してアクセストークンを取得するため、アクセストークンがユーザーエージェント（ブラウザ）に直接露出せず、バックエンドサーバーでセキュアに処理されるため。これにより、トークン窃取のリスクを低減できる。
  4. 脅威1: alg: noneによる署名スキップ。対策: JWTの署名検証時、algヘッダの値を固定化し、noneが指定された場合は拒否する。脅威2: 長寿命トークンによるリプレイ攻撃・窃取時の被害拡大。対策: exp（有効期限）を短く設定し、jti（一意識別子）を検証することでトークンの使い回しを防ぐ。また、リフレッシュトークンを導入し、アクセストークンの有効期限を管理する。
  5. IDaaSは、複数のSaaSやアプリケーションに対するID管理・認証基盤をクラウドで一元的に提供する。これにより、企業は個別のシステムごとに認証基盤を構築・運用する手間を省き（内製開発不要）、スケーラブルなID管理を実現できる。例えば、従業員がSalesforce, Google Workspace, Slackなど複数のサービスに一つのIDとパスワード（またはMFA）でSSOできる。
  6. セッションハイジャック: 攻撃者が正規ユーザーの有効なセッションIDを盗み出し、そのセッションIDを使って正規ユーザーになりすます攻撃。対策としては、セッションIDにSecure/HttpOnly/SameSite属性を付与し、認証後にセッションIDを再生成することが有効。CSRF (クロスサイトリクエストフォージェリ): ユーザーがログイン中に、悪意のあるサイトからのリクエストによって、ユーザーの意図しない操作（例: パスワード変更、購入）を強制的に実行させる攻撃。対策としては、各リクエストにCSRFトークンを含めて検証する、またはSameSiteクッキーのStrict/Lax設定が有効。
  7. 「alg: none攻撃」とは、JWTのヘッダにある署名アルゴリズムを示すalgフィールドに「none」を指定することで、署名検証がスキップされる脆弱性を悪用した攻撃。攻撃者は任意のペイロードを持つトークンを生成し、署名がないにも関わらず正当なトークンとして扱われることを試みる。この攻撃を防ぐためには、サーバー側でJWTの署名アルゴリズムを厳格に固定し、noneを拒否する必要がある。
  8. パスワードリスト型攻撃は、他のサービスから漏洩したIDとパスワードの組み合わせを使い回し、標的のサービスへのログインを試みる攻撃。対策1: IPアドレスやUser-Agentなどの情報に基づいたアクセス制限や異常検知。対策2: CAPTCHAの導入やリスクベース認証（ユーザーのログイン行動を分析し、リスクが高い場合にMFAなどを要求する）によって、不正なログイン試行を検出・阻止する。
  9. FIDO2/WebAuthnにおける「認証器（Authenticator）」は、ユーザーのデバイス（スマートフォン、PC内蔵のTPM、USBセキュリティキーなど）に存在し、ユーザーの公開鍵の秘密鍵を安全に保持・管理する役割を持つ。パスワードレス認証では、この認証器が秘密鍵を用いてチャレンジ応答に署名することで、フィッシング耐性の高い認証を実現し、ユーザーの認証情報をサーバーに送ることなく安全性を向上させる。
  10. 「自己主権型ID（SSI）」とは、ユーザー自身が自分のデジタルIDとその属性情報（学歴、職歴、ライセンスなど）を完全にコントロールし、必要に応じて検証可能な形で第三者（Verifier）に提示する概念。中央集権型ID管理がIdPに依存し、ユーザーのデータがIdPに集約されるのに対し、SSIではユーザー自身（Holder）が自身の資格情報（VC）を管理し、どの情報を誰に開示するかを自分で決定できるため、プライバシーとコントロールが強化される。

~Yu Tokunaga