AI Session Notes - 2026-04-04
2FA とセッショントークンの関係
学んだこと
ID/Passwordは本人確認の材料であり、session tokenやauth cookieは本人確認後に発行される認証済みの通行証に近い- 2FA は通常ログイン時の追加確認なので、認証済みセッションが漏れると 2FA を迂回して利用されることがある
ID/Passwordの漏えいは 2FA が追加の防壁になるが、session tokenの漏えいは即座に悪用しやすい場合がある- そのため、長寿命で広い権限を持つセッショントークンは、パスワード以上に慎重に扱うべきことがある
詳細
典型的な認証フローは次の順序になる。
ID/Passwordを入力する- 2FA で追加確認する
- サービスが
session tokenやcookieを発行する - 以後はそのトークンを使ってログイン済み状態を維持する
この構造では、漏えい時の危険性は次のように変わる。
ID/Passwordだけが漏れた場合: 攻撃者は次に 2FA を突破する必要があることが多い- 認証済み
session tokenが漏れた場合: 2FA 通過後の状態を引き継げる可能性がある
トークン貼り付け型ログインはセッション共有に近い
学んだこと
- 非公式アプリに
auth cookieやアクセストークンを貼り付ける方式は、パスワード入力を避けているだけで、本質的なリスクが消えているとは限らない - 認証済みトークンを外部アプリに渡す行為は、セッションハイジャックに近い性質を持つ
- 手動でトークンを取り出して貼り付けさせる UI は、UX 上の不安を減らしても、セキュリティ上の信頼性を保証しない
OAuthのような権限制限付きの委譲と、強い認証情報そのものを渡す方式は区別して考える必要がある
詳細
「ブラウザでログインして取得したトークンを非公式アプリに貼り付ける」という方式では、利用者は「パスワードを渡していない」と感じやすい。しかし実際には、認証済みセッションに相当する情報をアプリへ手渡している可能性がある。
これは典型的なセッションハイジャックと完全に同一ではないが、結果としては「ログイン済み状態を第三者が利用できる」という点でかなり近い。違いは、盗まれたか、自分で渡したかである。
非公式クライアントと非公式 API では信頼境界を自分で決める必要がある
学んだこと
- 非公式アプリを信用するかどうかだけでなく、そのアプリが依存する非公式 API やバックエンド全体まで含めて信頼対象になる
- UI 上で「ローカル保存」や「資格情報マネージャーで保護」と説明されていても、外部送信していない保証にはならない
ID/Passwordを入力させる方式でも、2FA 後に取得したトークンを収集される可能性はあるtoken入力方式でも、入力値をサーバーへ送って保存・再利用する実装は理論上あり得る- 認証情報が通過・保存・再利用され得る経路全体をどこまで信頼するかを、自分で線引きする必要がある
詳細
非公式クライアントを使う場合の信頼対象は、単一のアプリでは終わらない。
- クライアントアプリ本体
- クライアントが利用する非公式 API
- API の運営者とバックエンド実装
- ログや保存先などの周辺基盤
- 将来のアップデート後の挙動
そのため、「このアプリはパスワードを保存しません」という説明があっても、それだけでは不十分である。安全性を判断するには、権限の最小化、トークンの寿命、失効方法、通信先の透明性、実装の公開性などを総合して評価する必要がある。
メタ情報
- ツール: Codex
- 関連技術: 認証, 2FA, セッション管理, OAuth, アクセストークン, セキュリティ