認証基盤・パスキー・OAuth/OIDC

Aug 4, 202525 min

この章の到達目標

認証シーケンス図を追って、誰が、何を検証し、何を信頼しているのか を説明できるようにする。

2023年度のWebAuthn・証明書認証、2025年度の暗号鍵管理・認証基盤と関連する。SSOの設計問題にも備える。

1. 用語一覧

優先用語・技術科目Bで押さえるポイント
AFIDO2 / WebAuthn公開鍵認証、チャレンジ署名、RP IDとオリジン
Aパスキーデバイス保存型・同期型、秘密鍵と利用者検証
AOAuth 2.0認可フレームワーク、各登場主体とトークン
AOpenID ConnectIDトークンによる認証、OAuthとの違い
AAuthorization Code Flow認可コード交換、ブラウザー経由での処理
APKCEcode_verifier、code_challenge、コード横取り対策
Astate / nonceリクエスト関連付け・CSRF対策／IDトークンのリプレイ対策
AAccess Token / ID TokenAPIアクセスの認可と利用者認証情報の違い
AリダイレクトURI厳密な登録・検証、認可コードの漏えい防止
AMFA / フィッシング耐性OTP、プッシュ通知、FIDO2の攻撃耐性の違い
APKI / X.509証明書の信頼連鎖、SAN、CA、期限、失効
Aデジタル署名秘密鍵による署名、公開鍵による検証
BSAML 2.0IdP、SP、Assertion、署名・Audienceの検証
BSSO / フェデレーション認証連携、信頼関係、セッションの管理
BRefresh Token更新、ローテーション、盗難時の失効
BToken Replay盗まれたBearerトークンの再利用
BDPoP / mTLSトークンと鍵の結び付け、所有証明
BJWT / JWS / JWEトークン形式、署名と暗号化の区別
BRBAC / ABAC役割・属性によるアクセス制御
BEAP-TLS / 802.1X端末証明書、RADIUS、ネットワーク接続認証
BOCSP / CRL証明書の失効状態の確認
BHSM / TPM / Secure Enclave秘密鍵を保護するハードウェア機構
BKDF / Argon2id / PBKDF2パスワードからの鍵導出、ソルト・計算コスト
BJIT / JEA / PAM特権の必要時付与・機能限定・特権アクセス管理
B条件付きアクセスユーザー、デバイス、リスクなどに基づく制御
CSCIMIDのプロビジョニング・停止・削除の同期
CDevice Code Flowデバイスコードを悪用した認証誘導
CPAR / JAR / JARMOAuthリクエスト・応答の保護
CKerberosTGT、サービスチケット、相互認証
CPass-the-Hash / Pass-the-Ticket認証情報の再利用によるなりすまし

2. FIDO2 / WebAuthn / パスキー

2.1 登場主体

主体役割
認証器（Authenticator）秘密鍵を保持し、署名する（スマートフォン、セキュリティキー、PC内蔵のTPMなど）
クライアント（ブラウザー・OS）RPと認証器を仲介し、オリジンを確認する
RP（Relying Party）公開鍵を保存し、署名を検証するWebサービス

2.2 登録と認証の流れ

登録

  1. RPがチャレンジ（乱数）とRP IDを送る
  2. 認証器が利用者検証（生体認証やPIN）を行い、RP IDごとに 鍵ペアを生成する
  3. 公開鍵とクレデンシャルIDをRPに送る。秘密鍵は認証器から出ない

認証

  1. RPがチャレンジを送る
  2. ブラウザーが、アクセス中のオリジンとRP IDの対応を確認する
  3. 認証器が利用者検証の後、チャレンジなどに秘密鍵で署名する
  4. RPが保存済みの公開鍵で署名を検証する。チャレンジとオリジンが一致するかも確認する

2.3 なぜフィッシングに強いのか

  • 鍵がRP IDに結び付いているため、偽サイト（別のドメイン）では正規サイト用の鍵が使われない。
  • 署名データにオリジンが含まれ、RPが検証する。
  • チャレンジが毎回異なるため、署名を使い回せない（リプレイ耐性）。
  • RPが保存するのは公開鍵だけなので、RPから漏えいしても、なりすましには使えない。
方式フィッシング耐性理由
パスワードなし偽サイトに入力された値がそのまま使える
OTP（SMS、TOTP）弱い偽サイトが中継すれば、有効期間内に使われる（リアルタイムフィッシング）
プッシュ通知弱い大量に通知を送って承認させる攻撃（MFA疲労）。番号照合で緩和
FIDO2 / パスキー強いオリジンの検証と、ドメインごとの鍵

2.4 パスキーの種類

種類特徴考慮点
デバイス固定型秘密鍵が1台の認証器から出ない紛失時の復旧手段（複数登録）が必要
同期型クラウドのアカウントを通じて複数の端末に同期同期元アカウントのセキュリティに依存する

利用者検証（User Verification）は、認証器を持っている人が本人であることを確かめる手順。生体情報は認証器の中で照合され、RPには送られない。

3. OAuth 2.0 と OpenID Connect

3.1 OAuthとOIDCの違い

OAuth 2.0OpenID Connect
目的認可：APIへのアクセス権を委譲する認証：利用者が誰かを伝える
主なトークンアクセストークンIDトークン（JWT）
トークンの受け手リソースサーバ（API）クライアント（RP）

誤用の典型：アクセストークンを「ログインの証明」として使う。アクセストークンは別のクライアント向けに発行されたものかもしれず、利用者の認証には使えない。認証にはIDトークンを使い、aud が自分のクライアントIDであることを検証する。

3.2 登場主体

主体役割
リソースオーナー利用者
クライアント利用者の代わりにAPIを使うアプリ
認可サーバ利用者を認証し、トークンを発行する（OIDCではOP / IdP）
リソースサーバアクセストークンを検証してAPIを提供する

3.3 認可コードフロー＋PKCE

  1. クライアントが code_verifier（乱数）を生成し、そのハッシュ値を code_challenge とする
  2. ブラウザーを認可サーバへリダイレクトする（client_id、redirect_uri、state、nonce、code_challenge を付ける）
  3. 認可サーバが利用者を認証し、同意を得る
  4. 認可サーバが redirect_uri に認可コードと state を付けてリダイレクトする
  5. クライアントが state を照合する
  6. クライアントが バックチャネル で認可コードと code_verifier を送り、トークンを受け取る
  7. 認可サーバは code_verifier のハッシュ値が code_challenge と一致するか検証する

3.4 各パラメータが防ぐもの

パラメータ防ぐ攻撃検証する主体
stateCSRF（攻撃者の認可コードを被害者のセッションに紐付ける）クライアント
nonceIDトークンのリプレイクライアント（IDトークン内の値と照合）
PKCE認可コードの横取り（不正なアプリ、ログへの記録）認可サーバ
redirect_uri の完全一致認可コードを攻撃者のURLに送らせる認可サーバ

redirect_uri を前方一致やワイルドカードで検証していると、攻撃者が用意したパスやサブドメインに認可コードが送られる。事前に登録したURIとの完全一致 が原則である。

3.5 トークンの保護

  • Bearerトークン：持っている者は誰でも使える。漏えいするとそのまま再利用される（Token Replay）。
  • 有効期限：アクセストークンは短く、リフレッシュトークンで更新する。
  • リフレッシュトークンのローテーション：使うたびに新しいものを発行し、古いものが再度使われたら、盗難と判断して一連のトークンを失効させる。
  • 送信者制約（Sender-Constrained）：DPoPやmTLSでトークンを鍵に結び付け、鍵を持たない者には使えなくする。

3.6 補強（C）

  • Device Code Flow：入力しにくい機器向け。攻撃者が取得したコードを被害者に入力させ、トークンを攻撃者に発行させるフィッシングに注意する。不要なら無効にする。
  • PAR：認可リクエストをバックチャネルで事前に登録し、ブラウザーにはその参照だけを渡す。改ざんや情報漏えいを防ぐ。
  • JAR / JARM：認可リクエスト・応答をJWTで署名する。

4. SAML 2.0

主体役割
IdP利用者を認証し、Assertion（属性や認証結果）を発行する
SPAssertionを検証してサービスを提供する

SPが検証すべき項目：

項目欠落した場合
署名改ざんしたAssertionを受け入れる
Audience別のSP向けのAssertionを流用される
NotOnOrAfter などの有効期間古いAssertionを再利用される
InResponseToSPが発行していない要求への応答を受け入れる
Destination / Recipient別の宛先向けのAssertionを受け入れる

IdPの署名鍵が漏えいした場合、攻撃者は任意の利用者のAssertionを作成でき、連携しているすべてのSPに影響する。IdPはSSOの単一障害点であり、最も厳重に保護すべき資産である。

5. PKIと証明書

5.1 信頼の連鎖

ルートCA → 中間CA → サーバ証明書 の順に、上位の秘密鍵で下位の証明書に署名する。検証する側は、トラストストアに登録されたルートCA証明書まで辿れるかを確認する。

サーバ証明書の検証項目：

  • 信頼できるルートCAまで署名を辿れるか
  • 有効期間内か
  • アクセス先のホスト名がSAN（Subject Alternative Name）に含まれているか
  • 失効していないか（CRL、OCSP）
  • 用途（Key Usage、Extended Key Usage）が適切か

5.2 失効の確認

方式仕組み特徴
CRLCAが失効した証明書の一覧を公開するリストが大きくなる。更新の間隔だけ遅れる
OCSP個別の証明書の状態を問い合わせる問合せ先が利用者のアクセス先を知ることができる。応答できないと可用性に影響
OCSPステープリングサーバがOCSP応答を取得してTLSハンドシェイクで提示するクライアントの問合せが不要

5.3 デジタル署名

  • 送信者が 秘密鍵 で署名し、受信者が 公開鍵 で検証する。
  • 確認できること：完全性（改ざんされていない）、真正性（その秘密鍵の持ち主が署名した）、否認防止。
  • 公開鍵が本当にその相手のものであることは、証明書（CAの署名）で保証する。

6. 鍵の管理（2025年度関連）

鍵の管理は「暗号アルゴリズムの強さ」よりも出題されやすい。暗号が破られるより、鍵が漏えいする方がはるかに現実的だからである。

ライフサイクル確認すること
生成十分な乱数性。HSMの内部で生成し、外に出さない
保管ソースコードや設定ファイルに直書きしない。HSM、KMS、シークレット管理サービスに保管する
利用用途ごとに鍵を分ける（署名用と暗号化用、環境ごと）
ローテーション定期的、および漏えいの疑いがあるときに更新する。旧鍵での検証期間を設ける
失効・破棄証明書の失効、鍵の確実な削除
アクセス制御鍵を使える人・サービスを限定し、利用をログに残す
機構特徴
HSM耐タンパー性を持つ専用装置。秘密鍵を外部に出さずに署名・復号する
TPMPCのマザーボードに搭載されるチップ。端末に紐付けた鍵の保管、起動時の完全性の計測
Secure EnclaveスマートフォンなどのSoC内の隔離領域
クラウドKMS鍵の管理と利用をAPIで提供。IAMで利用者を制御する

エンベロープ暗号化：データをデータ鍵（DEK）で暗号化し、DEKをマスター鍵（KEK）で暗号化して保存する。KEKはKMSやHSMの外に出ない。鍵のローテーションはKEKの更新で済む。

6.1 パスワードの保存

  • 平文や可逆な暗号化で保存しない。
  • 単純なハッシュ関数（SHA-256の1回だけなど）は高速すぎるため、総当たりに弱い。
  • ソルト（利用者ごとの乱数）で、同じパスワードが同じ値にならないようにし、事前計算表による解析を防ぐ。
  • 計算コストを調整できる関数（Argon2id、bcrypt、scrypt、PBKDF2）を使う。

7. 特権とアクセス制御

用語内容
RBAC役割に権限を割り当てる
ABAC利用者・資源・環境の属性で判断する（部署、機密度、時間帯、端末の状態）
条件付きアクセス利用者、端末の準拠状態、場所、サインインのリスクに応じて、許可・MFAの要求・拒否を決める
JIT特権を必要なときだけ、期限付きで付与する
JEA実行できるコマンドを限定した管理用の権限
PAM特権IDの貸出し・承認・操作の記録を一元管理する
SCIM人事システムなどからIDの作成・停止を自動で同期する。退職者のアカウントが残る問題を防ぐ

8. Windows・AD環境の認証（C）

sc_5 のインシデント対応と関連する。

  • Kerberos：KDCが発行するTGTで、サービスチケットを取得する。相互認証が可能。
  • Pass-the-Hash：NTLM認証では、パスワードの代わりにハッシュ値そのものが認証に使える。端末から窃取されたハッシュ値で、別の端末にログオンされる。
  • Pass-the-Ticket：窃取したKerberosチケットの再利用。

対策の方向性：特権アカウントで一般端末にログオンしない（階層化）、ローカル管理者のパスワードを端末ごとに変える（LAPS）、NTLMの制限、Credential Guardなどによる資格情報の保護。

9. ネットワーク接続の認証：802.1X / EAP-TLS

主体役割
サプリカント端末
オーセンティケーター無線LANのアクセスポイント、スイッチ
認証サーバRADIUSサーバ
  • EAP-TLSは、クライアント証明書 とサーバ証明書の両方で相互に認証する。パスワードを使わない。
  • 端末は、RADIUSサーバの証明書を検証すべきである。検証しないと、偽のアクセスポイントと偽の認証サーバに接続してしまう。
  • 証明書を端末にインストールする際、秘密鍵をエクスポートできない設定にすると、別の端末への持出しを防げる。TPMに保管するとさらに強い。

10. シーケンス図を読むときのチェックリスト

  1. 各矢印で 何が送られているか（チャレンジ、署名、コード、トークン、Assertion）
  2. 受け取った側が 何を検証しているか（署名、宛先、有効期限、乱数の照合）
  3. ブラウザーを経由する 値はどれか（改ざん・横取りされうる）
  4. 秘密鍵・共通鍵 はどこにあり、誰がアクセスできるか
  5. その鍵が漏えいしたら、どの範囲 に影響するか

~Yu Tokunaga