認証フレームワーク

Kerberos（対称鍵＋チケット）、SAML（フェデレーションID＋XMLアサーション）、WebAuthn（公開鍵＋ローカル生体認証）——3つの認証フレームワークは、それぞれドメイン内、クロスドメイン、フィッシング対策という異なる3つのシナリオを解決します。LDAPとRADIUSは、インフラストラクチャ層でディレクトリおよびネットワークアクセス制御を提供します。

概要

「認証」が常に答えなければならない問いは同じです——⁠いかにして自分が自分であることを証明するか⁠。しかし、異なるプロトコルは「証明」を異なる位置に配置しており、それによっていくつかの世代に分かれます：

理解すべき主軸は一つだけです：⁠パスワードは負債である⁠。パスワードは再利用され、フィッシングの餌食となり、辞書攻撃を受け、伝送中や保存中に漏洩します。後続の各世代のプロトコルは、パスワードの出現回数を減らす方法を模索してきました——Kerberosはパスワードをローカルでの派生に1回だけ使用し、それ以降はネットワークに送信しません。SAML/OIDCは、パスワードをIdPという1か所にのみ渡すようにします。WebAuthnは、デバイス内のエクスポート不可能な秘密鍵を用いてパスワードを完全に置き換えます。選択の本質は、⁠既存のインフラストラクチャと脅威モデルにおいて、パスワードをどの程度排除できるかにあります。

Kerberos — チケットによるシングルサインオン

Active Directoryドメインログインの基盤です。核心的な思想は、ユーザーがログイン時にのみパスワードから1回鍵を派生し、その後は期限付きの対称暗号化チケットによって各サービスにアクセスし、パスワードはネットワークを通過しないというものです。

なぜこのように設計されたのか：サーバーはKDCに連絡する必要もなく、ユーザーのパスワードを保存することなくクライアントを検証できる——「自分の鍵で暗号化されたチケット」を解読できれば、そのチケットがKDCによって発行されたことが証明される。代償と脅威：

• 時刻同期⁠：authenticatorはタイムスタンプによってリプレイ攻撃を防ぐため、ドメイン全体の時刻のずれは通常5分未満でなければならない（そのためADはNTPに強く依存する）。
• KDCは高価値の単一障害点⁠：krbtgt アカウントのハッシュを取得すれば、任意のTGTを偽造できる（Golden Ticket）。あるサービスの鍵を取得すれば、そのサービスのチケットを偽造できる（Silver Ticket）。
• Kerberoasting：サービスチケットはサービスアカウントのパスワードから派生した鍵で暗号化されるため、攻撃者はチケットを要求してからオフラインで弱いパスワードのサービスアカウントを爆破できる——そのため、サービスアカウントには強力なランダムパスワードまたはgMSAを使用する必要がある。

LDAP — ディレクトリおよびbind認証

LDAP（RFC 4511）はまず階層型ディレクトリ⁠（cn=alice,ou=users,dc=example,dc=com）であり、ユーザー、グループ、デバイスおよびその属性を格納する。その「認証」とは、bind操作のことである：DNとパスワードを使用してサーバーから「許可/拒否」を取得する。

位置づけの要点：LDAP自体はSSOプロトコルではない⁠、それは「資格情報検証 + 身元データソース」であり、SAML/OIDC/RADIUSの背後に隠れてストレージとしてよく使用される。Active Directory ≈ LDAP（ディレクトリ）+ Kerberos（認証）+ DNS（ルーティング）の3点セットの組み合わせである。

SAML 2.0 — 企業Web SSO

XML時代のブラウザ向けSSO標準（Okta、Azure AD、企業内網）。SP（サービスプロバイダ）は認証をIdP（アイデンティティプロバイダ）に「外部委託」し、IdPはデジタル署名付きのアサーション（Assertion）⁠を返す。

セキュリティの要点（SAMLの落とし穴のほとんどは署名検証にある）：

• XML Signature Wrapping (XSW)：攻撃者が合法な署名付き要素の位置をずらし、偽造されたアサーションを注入する。SPは「署名が適用されているのが、まさに信頼されるべき要素であること」を厳密に検証し、スキーマ解析を固定する必要がある——これがSAML実装で最も一般的なCVEの発生源である。
• Audience（このアサーションは自分宛てであること）、NotOnOrAfter（期限切れでないこと）、RecipientおよびInResponseTo（リプレイ攻撃/注入防止）、NameIDの単一消費を検証する必要がある。
• なぜまだ生き残っているのか：純粋なブラウザリダイレクト、JavaScript不要、レガシーな企業IdPとの互換性が最高である。新規プロジェクトではOIDCが首选である。

WebAuthn / Passkeys — フィッシング耐性のあるパスワードレス

FIDO2/WebAuthn（W3C）は非対称鍵のペアを用いてパスワードを置き換える：秘密鍵は生成後にデバイスのセキュリティユニットにロックされ、エクスポート不可であり、サーバーは公開鍵のみを保存する。

それが唯一真に重要な性質はフィッシング耐性である⁠：署名にはorigin/RP IDがバインドされており、ブラウザはexample.comの資格情報をexample.comに対してのみ使用する。ユーザーがexamp1e.comに騙された場合でも、Authenticatorは一致する資格情報を見つけられず、有効な結果に署名できない——これはパスワード、OTP、プッシュ通知では提供できない保証である。その他の概念：

• attestation：「これは某モデルの正規品Authenticatorである」ことを証明する。消費シナリオでは通常検証しない（プライバシー + 互換性の理由）。
• discoverable credential（resident key）：ユーザーハンドルをAuthenticatorに保存し、「ユーザー名を入力せずにログインする」を実現する——これがPasskeyの基盤である。
• Passkey = 同期可能なdiscoverable資格情報⁠：iCloud Keychain / Google Password Managerを介してデバイス間で同期され、使いやすさが大幅に向上するが、信頼はクラウドアカウントに移行する。ハードウェアキー（device-bound）は同期されず、より強力だが紛失しやすい。

RADIUS — ネットワークアクセスのAAA

RADIUS（RFC 2865）が管理するのは「ウェブサイトのログイン」ではなく、「⁠このネットワークに接続できるか⁠」——WiFi（WPA2/3-Enterprise）、VPN、スイッチポート（802.1X）である。AAAを行う：Authentication（認証）、Authorization（認可）、Accounting（監査）。

要点：RADIUS自体は単なるAAAフロントエンドであり、アイデンティティデータは通常LDAP/ADにある。それは「アクセス層」と「アイデンティティ層」を分離する。コマンド単位での細粒度な認可と監査（ネットワーク機器の運用保守）が必要な場合は、TACACS+（コマンド単位認可、全体暗号化）に置き換える。

選択基準

実践では、これらは排他的選択ではなく階層的に組み合わせて使用される：典型的な組み合わせは、WebAuthn/OIDCをユーザーログインのフロントエンドとして、LDAP/ADをアイデンティティソースとして、Kerberos/RADIUSを内網とアクセス制御として使用するものである。

参考

• Kerberos: RFC 4120 · MIT Kerberosドキュメント · 「Kerberos: The Definitive Guide」
• WebAuthn: w3c.github.io/webauthn · webauthn.guide · passkeys.dev
• SAML: OASIS SAML 2.0 Core · 「On Breaking SAML」（XSW攻撃論文）
• 統一プラットフォーム⁠: Keycloak（OIDC/SAML/LDAP/Kerberosのブローキングを同時に解説、実際に構築して読む価値あり）

Keywords: Kerberos, KDC, TGT, Golden Ticket, Kerberoasting, LDAP, bind, SAML, Assertion, XML Signature Wrapping, WebAuthn, Passkey, FIDO2, phishing-resistant, RADIUS, EAP, 802.1X, TACACS+