OAuthは、パスワードを渡さずに「あるサービスの自分のデータを、別のアプリに必要な範囲だけ使わせる」仕組みです。カギになるのがアクセストークン＝範囲と期限が限られた合鍵。パスワードという“親鍵”を渡す代わりに、限定された合鍵だけを渡すので、漏れても被害が限られます。
利用者（データの持ち主）／使いたいアプリ（＝クライアント。あなたのデータを使いたい側）／資源を持つサービス（データの置き場）／認可サーバ（合鍵＝トークンを発行する窓口）。ポイントは、アプリは利用者のパスワードを一度も受け取らないことです。
合鍵（トークン）が渡るまでの流れ
「同意 → 引換券（認可コード） → 合鍵（トークン） → 範囲内で利用」。パスワードは認可サーバにしか渡らず、アプリが手にするのは限定された合鍵だけです。
動きで見る
番号順に追うと、同意 → 引換券（認可コード） → 合鍵（アクセストークン） → 範囲内で利用の流れが見えます。パスワードは認可サーバにしか渡りません。（図は横スクロールできます）
なぜトークンなら安全側なのか
アクセストークンは範囲（scope）と期限が限られた合鍵です。だからパスワード共有と違い、漏れても「その範囲・その期限まで」しか悪用できない。設問では「なぜパスワードを渡さずに済むか／トークンが漏れたときの影響範囲／有効期限で被害をどう抑えるか」が問われます。親鍵（パスワード）と合鍵（トークン）の違いを軸に読むと答えが決まります。
認証（＝あなたが誰か）と認可（＝何を許すか）は別物です。OAuthは元々認可の仕組み。「本人確認そのもの」を上に載せたい場合は、その上の層（IDトークンを扱う仕組み）を足します。「誰か」を確かめたいのか「何を許す」のかを取り違えないのが急所です。
横取りを防ぐ小さな工夫
引換券（認可コード）やトークンを途中で奪われないよう、次のような手当てが問われます。
引換券の横取り対策
- アプリ本人だけが交換できる合言葉を後から突き合わせる
- 横取りした認可コードだけではトークンに換えられない
使い回し・なりすまし対策
- 1回限りの値で応答の紐づけを確認
- 期限切れは更新用トークンで取り直す（合鍵を短命に）