Mímisbrunnr知恵の泉

← サイバーセキュリティ 一覧

🎓 レベル：発展　|　重要度：B（推奨） 📎 前提：セッションとトークン（JWT）

要点（BLUF）

概念：パスワードを渡さずに権限を貸す

あるアプリに「あなたの写真ストレージへアクセスしてよい」と許可したいとき、ストレージのパスワードを渡すのは危険です（全権を渡すことになる）。OAuth 2.0 は、パスワードを渡さずに、限定された権限だけを安全に委譲する仕組みです。鍵を渡す代わりに「この棚だけ開く一時パス」を発行するイメージです。

ここで重要な区別：

OAuth は本来「権限の委譲」のための枠組みで、本人確認そのものではありません。本人確認を標準化するために OAuth の上に OIDC を重ねます。

仕組み：OAuth 2.0 の登場人物と認可コードフロー

登場人物（ロール）は4つです。

現在の推奨フローは**認可コードフロー（+ PKCE）**です。アクセストークンを直接ブラウザに晒さず、いったん使い捨ての「認可コード」を経由して、サーバ間でトークンに交換します。PKCE はコード横取りを防ぐ拡張で、モバイルや SPA でも必須級です（要最新確認）。

sequenceDiagram
    participant U as 利用者
    participant C as クライアントアプリ
    participant A as 認可サーバ（IdP）
    participant R as リソースサーバ（API）
    U->>C: この機能を使いたい
    C->>A: 認可リクエスト（範囲＝scope を指定）
    A->>U: ログインと同意の確認
    U->>A: 同意（パスワードはIdPにのみ渡す）
    A->>C: 認可コードを返す
    C->>A: コードをアクセストークンに交換
    C->>R: アクセストークンでAPI呼び出し
    R->>C: 許可された範囲のデータのみ返す

ポイントは、利用者のパスワードはクライアントアプリに渡らないこと（認可サーバにだけ渡る）。クライアントが受け取るのは、範囲（scope）が絞られたトークンだけです。

仕組み：OpenID Connect（認証層）

OAuth はトークンを発行しますが、それは「権限の証」であって「本人の証明」ではありません。OIDC は OAuth に ID トークン（JWT） を追加し、「誰がいつどの IdP で認証されたか」を検証可能な形で標準化します。これにより、複数サービスで1つの ID を使う SSO（シングルサインオン） が安全に実現できます。ID トークンは署名つき JWT なので、検証は セッションとトークン（JWT） の作法（署名検証・許可 alg 固定・発行者と対象者の確認）に従います。

防御側の使い方／設定

なぜ安全か：パスワード非共有＋範囲限定＋本人確認の分離

OAuth/OIDC が安全なのは3点です。(1) パスワードを IdP 以外に渡さないので、クライアント漏えいでも資格情報は守られる。(2) トークンは scope で範囲が絞られ、漏れても被害が限定される（最小権限）。(3) 「権限（OAuth）」と「本人確認（OIDC）」を分離し、それぞれ適切なトークンで検証する。役割を混ぜないことが設計上の安全につながります。

仕組みの直観

OAuth はホテルのバレーキーです。車のすべての機能を開くマスターキーではなく、エンジン始動と短距離移動だけ許す限定キーを係員に渡す。あなたの本物の鍵（パスワード）は渡しません。OIDC はそこに身分証の提示を足したもので、「この係員は確かに当ホテルが認証した本人だ」と保証する仕組みです。

⚠️ よくある誤解・設定ミス

対応 lab

外部 IdP との連携が前提のため専用 lab は置きません。トークン（ID トークン＝JWT）の署名検証は security-study/labs/jwt_verify_demo.py の作法がそのまま当てはまります。

関連