ログインできた人を、どこまで信用するのか

架空事例：青葉機材の取引先ポータルを用いる営業担当・顧客担当・配送会社の権限を考える。仕様の解釈はOpenID Connect Core 1.0とNIST SP 800-63-4（2025年最終版）などの公開資料へ照合した。実在の認証基盤を操作・評価した記録ではない。

退職した社員の画面が、まだ開いている

取引先の担当者は会社を退職した。管理者は名簿から氏名を削除した。それでも、本人がログイン済みのブラウザを開くと、過去の予約一覧を表示できた。

名簿が変わっても、セッションと権限が変わるとは限らない。ログイン時に本人を確認した事実と、現在その操作が許されるかどうかは別である。

青葉機材のシステムは、取引先の従業員という属性を外部のIDプロバイダから受け取り、社内の契約先情報と結び付けていた。ここで「認証できた」という結果だけをキャッシュし続ければ、契約先との関係が変わったときに閲覧可否へ反映されない。

だから、認証、認可、権限の変更、セッションの失効を異なるライフサイクルとして設計する。原教材第20章のSSOと、第21章の認証・認可の区別は、ログイン後の時間軸を考えたときに初めて具体的になる。1

身元確認と、ログイン時の証明は違う

利用者が本当に誰なのかを登録する過程と、登録済みの利用者が再び操作するときの認証は異なる。NIST SP 800-63-4は、本人確認・登録、認証、連携認証を分け、それぞれの要求を定義する資料である。2

例えば、取引先企業が担当者の雇用関係を確認してアカウントを発行することと、その担当者がログイン時に認証器を使うことは別の出来事である。本人確認の証拠が十分でも、パスワードを盗まれればログイン操作は悪用され得る。逆に強固な認証方式を採用しても、初期登録で別人へアカウントを発行すれば正しい本人と結び付かない。

ログイン後に本人の識別が成立しても、予約の削除権限はまだ決まらない。役割、所属組織、対象データ、操作種別、承認状況などを用いて許可を判断する。システムが主体を知っていることと、その行為を承認していることを混同しない。

ワンタイムパスワードの強みには限界がある

パスワードだけでなく、時間とともに変わるコードを入力させた。攻撃者が一度見たコードを後から使い回しにくくなる。しかし、攻撃者が本物そっくりのログイン画面を作り、利用者がそこへ現在有効なコードを入力したらどうなるだろう。

入力されたコードを、攻撃者が正規の認証先へすぐ中継できる可能性がある。使い回しへの耐性と、偽の認証先に対する耐性は同じではない。

NIST SP 800-63B-4は、手入力によるOTP認証器をフィッシング耐性のある認証方式とは扱わず、認証出力を検証先やセッションへ暗号学的に結び付ける考え方を示す。3 WebAuthn/FIDO2などは、検証先のドメインと認証動作を結び付ける方式の例である。

とはいえ、フィッシング耐性を持つ認証器を導入するだけで、他社予約の閲覧を防げるわけではない。強い認証と対象ごとの認可を両方持つ必要がある。

SSOは、アプリケーションの権限を消さない

取引先ポータル、配送照会、請求書システムへ、一回のログインで入れるようにした。これがSSOの利用者体験である。だが、三つのアプリケーションに同じ操作権限を付与するという意味ではない。

OpenID Connect Core 1.0はOAuth 2.0の上に本人認証の層を設け、認証結果をIDトークンなどでクライアントへ伝える。4 OAuth 2.0のアクセストークンは、主として保護されたリソースへのアクセス権を示すためのものであり、IDトークンの代用品ではない。

青葉機材の請求書アプリケーションは、IdPで認証された主体がどの契約先へ所属するかを確認し、その契約先の請求書に限ってアクセスさせる。認証基盤が署名した情報を検証しても、請求書の番号だけで許可してはいけない。

トークンを扱う側には、署名、有効期限、発行者、想定した受信者といった文脈の検証が必要になる。単に「JWTだから正しい」という判断は成り立たない。トークン形式と信頼できる発行・検証の手続は別である。

セッションは、過去の認証を将来へ持ち越す

認証成功後、ブラウザはセッションを持つ。認証器を毎回操作しなくても継続利用できる。その利便性の代わりに、セッション識別子を盗まれた場合や権限が変更された場合にどうするかを決める必要がある。

OWASPのセッション管理ガイドは、推測困難なセッション識別子、ログインなど権限変化時の識別子更新、適切な寿命と失効を扱う。5 認証前の識別子を認証後にも使わせ続けると、セッション固定攻撃に結び付く場合がある。

有効期限を一つだけ定めれば十分とは限らない。長時間操作していないこと、認証から一定時間経過したこと、ログアウトしたこと、管理者が権限を剥奪したことは異なる条件である。「有効なCookieがある」という事実だけで、最新の業務権限まで保証できない。

端末を共有する現場では、ログアウトや端末紛失時の操作も重要になる。ブラウザのタブを閉じたからサーバ側セッションが必ず無効になるわけではない。誰が何を失効させる権限を持つのか、業務側で定義する必要がある。

ロールは便利だが、会社境界を表し切れない

取引先担当者というロールを付与した。しかし、青葉機材には百の取引先がある。同じロールの利用者同士が、それぞれの契約先の予約を閲覧できる設計でなければならない。

ロールベースのアクセス制御は「営業」「配送」「管理者」といった責務ごとに権限をまとめるのに役立つ。ただし、どの会社の、どの予約を扱うかという対象の関係も必要になる。役割だけで対象の境界を表すなら、百社すべての個別ロールを増やす設計へ陥ることがある。

属性ベースや関係ベースの判断は、主体・資源・環境の条件を組み合わせられる。名称を導入すれば自動的に正しいわけではないが、どこへ判断の根拠を置くかを意識できる。OWASPも、サーバ側で資源ごとのアクセス制御を検査することを重視している。6

青葉機材では、配送担当が担当する便の配送先を読むことは許すが、同じ顧客の値引き履歴は読ませない。項目の公開範囲にも制御が必要だ。APIの入口が許可されているという理由で、返却する全属性を許可したことにはならない。

代理実行と緊急操作は、通常の権限を拡大しない

顧客が電話で予約変更を依頼した。営業が代理で操作する。このとき、システム上の操作主体は営業担当であり、変更を依頼した顧客とは異なる。

顧客のIDをそのまま営業のセッションへ入れて操作すれば、誰が実行したのか追跡しにくくなる。代理実行を業務機能として定義し、誰の代理で、どの権限に基づき、どの範囲を変更したかを残す必要がある。

障害時に通常より強い権限を一時付与することもある。緊急操作の必要性と、無期限の管理者権限を付与することは同じではない。利用できる時間、承認、監査、終了条件を明らかにする。ログに機密情報を書きすぎれば、今度は監査機構が漏えい経路になる。

設計したいのは、パスワード入力画面だけではない。時間が経過し、組織と権限が変わっても、許可の判断が業務の現実に追従する仕組みなのである。

知識を答案へ戻す

午前Ⅱ。 認証と認可、IDトークンとアクセストークン、OTPの再利用防止とフィッシング耐性、セッション更新とログアウトの役割を区別する。

午後Ⅰ。 誰がどの時点の所属情報で認証されたか、現在の対象別権限は何か、どこで失効を判断するかを本文から抽出する。

午後Ⅱ。 SSO採用の範囲、各アプリケーションの認可責任、権限変化の伝播、代理操作の証跡について代替案と選定理由を説明する。

立ち止まって考える：取引先の担当者が退職した。IdPからアカウントを削除するだけで、すべての閲覧を直ちに止められるか

各アプリケーションのセッション・トークン・権限キャッシュ・対象別認可の設計に依存する。登録情報を変更する操作と、既に確立された利用状態を失効させる操作を分けて確かめる。

出典と照合範囲

[1] コンプリートテキスト第2・20・21・23章、IPA SAシラバスVer.5.2：認証・認可・非機能要件・運用の区別を出発点とする。公式シラバス

[2] NIST SP 800-63-4（2025年最終版）：Identity Proofing、Authentication、Federationの対象の違いを参照した。公式資料

[3] NIST SP 800-63B-4：OTPとフィッシング耐性、検証先への結び付きを参照した。認証器に関する節

[4] OpenID Connect Core 1.0（errata set 2）：OAuth 2.0上の認証層、IDトークン、発行者や受信者の文脈を参照した。公式仕様

[5] OWASP Session Management Cheat Sheet：セッション識別子、権限変化時の更新と管理を参照した。公式解説

[6] OWASP Authorization Cheat Sheet：拒否を既定とする認可と、資源ごとの検査を参照した。公式解説