認証フレームワーク

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 に対しては一度きりの消費を行うこと。
• なぜまだ生き残っているのか：純粋なブラウザリダイレクトであり、JSを必要とせず、レガシーな企業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+