OAuth 2.0 と OIDC — 「代理で使わせる」と「誰かを証明する」は別物

What — 認可コードフローを一歩ずつ

OAuth の手順は一見遠回りです。しかし1つずつに理由があります。

各ステップが防いでいるもの

OAuth と OIDC の違い

得られるもの: アクセストークン

→ 「このトークンの持ち主は
    カレンダーの読み取りをしてよい」

誰のものかは、トークン自体からは分からない

Why — なぜパスワードを渡さない形にしたのか

OAuth 以前、外部サービスに自分のデータを使わせる方法はパスワードを渡すことでした。「連絡先をインポートします、メールのパスワードを入力してください」という画面が実在しました。

この方式の問題は明らかです。

• 権限を絞れない。 連絡先を読みたいだけなのに、メールの送信も削除もできてしまう
• 取り消せない。 使わせるのをやめたければ、パスワードを変えるしかない。他のサービスも全部止まる
• 保存される。 渡した先がパスワードをどう保管しているか分からない

OAuth は「パスワードを渡さずに、限定的な権限だけを、いつでも取り消せる形で委譲する」ために作られました。

なぜトークンを直接渡さないのか

初期の OAuth 2.0 には、認可サーバーがトークンを直接ブラウザに返す Implicit フロー がありました。手順が短くて簡単です。

しかし、トークンが URL のフラグメントに乗るため、次の経路で漏れます。

• ブラウザの履歴に残る
• 拡張機能や他のスクリプトから読める
• Referer ヘッダで外部に送られる可能性がある

現在 Implicit フローは非推奨です。代わりに、ブラウザには一度きりの引換券（認可コード）だけを渡し、実際のトークンはサーバー間の直接通信で受け渡す形になりました。

PKCE がなぜ後から追加されたのか

client_secret は、サーバーサイドのアプリなら安全に保管できます。しかしモバイルアプリや SPA は、配布した時点で中身が読まれます。secret を埋め込んでも秘密になりません。

secret を使えないと、認可コードを盗んだ攻撃者がトークンに交換できてしまいます。そこで PKCE は、secret の代わりに、その場で作った使い捨ての値を使います。

1. アプリがランダム値 code_verifier を作る
2. そのハッシュ code_challenge を、最初のリダイレクトに乗せる
3. トークン交換時に code_verifier そのものを送る
4. 認可サーバーがハッシュを計算し、最初の code_challenge と一致するか確認する

コードを盗んだ攻撃者は code_verifier を知らないので、交換できません。事前に「答えのハッシュ」を預けておき、後から「答え」を見せるという構造です。

現在は、サーバーサイドアプリでも PKCE を併用するのが推奨です。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。