OAuth 2.0

どんな仕組みか

OAuth 2.0 は、パスワードを相手に渡さずに「ここまでアクセスしてよい」という権限だけを第三者へ委譲するための標準仕様です。鍵となるのは「アクセス委譲（認可）」であって、本人確認そのものではありません。

たとえば、あるアプリに「Google ドライブの特定ファイルだけ読ませたい」とき、Google のパスワードをアプリに教える代わりに、限定された権限を持つアクセストークンを発行して渡します。

どう動くのか

利用者がアプリの要求を承認すると、認可サーバがアクセストークンを発行します。アプリはそのトークンを付けて API を呼び、リソース側はトークンの正当性と範囲を確認して応答します。

• スコープ（scope）で「読み取りだけ」「特定の範囲だけ」と権限を絞り込める
• トークンには有効期限があり、リフレッシュトークンで更新できる
• 実際の権限取得の流れは「認可コードフロー」など複数のグラントタイプがある

他の方式との違い

OAuth 2.0 が扱うのはあくまで「何にアクセスしてよいか」という認可です。「誰がログインしたのか」という本人確認（認証）は対象外で、その役割は上に乗せる OpenID Connect が担います。

「○○でログイン」と書かれていても、ログイン（認証）部分は OIDC、外部サービスへの API 連携部分は OAuth 2.0、と整理すると混乱しにくくなります。

使いどころ・注意点

SaaS 同士の連携や、外部アプリに自社 API を使わせる場面の土台として広く使われます。スコープを最小限に絞り、トークンの有効期限と保管を適切に管理することが安全運用の前提です。

OAuth 2.0 を「ログインの仕組み」と誤解したまま認証に流用すると、本人確認の保証が不十分になります。認証が必要なら OIDC を併用します。