OAuth 2.0 は、他のサービスへ権限を安全に委ねるための仕組みです。
ログインで見かけることも多いですが、本来は 認可 のための仕組みで、認証そのものとは少し役割が違います。
まず押さえたいポイント
- 本来は認可の仕組み
- 別サービスへ権限を渡すときに使う
- 認証では OpenID Connect とセットで語られやすい
どんな場面で使うか
どんなふうに理解するとよいか
このサービスに、別サービスの情報へアクセスしてよいか を安全に扱う仕組みと考えると分かりやすいです。
ログイン機能の文脈では、OpenID Connect が OAuth 2.0 を土台にして認証も扱えるようにしています。
押さえておきたい注意点
OAuth 2.0 だけで認証まで全部説明しようとすると、意味がずれやすいです。
認可 と 認証 を分けて考えることが大事です。
仕組み：なぜパスワードを渡さずに済むのか
OAuth 2.0 の要点は、連携先にパスワードを渡さないことです。代わりにアクセストークンという「限定された鍵」を渡します。この鍵はできること（スコープ）と期限が絞られているので、万一漏れても被害を限定でき、パスワードを変えずに連携だけ取り消せます。
現在の標準的な流れは認可コードフロー＋PKCEです。いったん短命な「引換券（認可コード）」を受け取り、それをトークンに交換します。PKCE は、その引換券を横取りされても使えなくする追加の仕組みで、今はスマホアプリだけでなくWebアプリでも推奨されています。逆に、URLに直接トークンを返す暗黙フロー（Implicit）は非推奨なので、古い記事を参考にするときは注意します。
実務で見るポイント
設計で効くのはスコープを最小限にすることです。「とりあえず全権限」を要求するとユーザーに警戒され、漏洩時の被害も大きくなります。あわせてリフレッシュトークンの保管場所（漏れると長期間悪用される）と失効の手段を用意しておきます。認証まで扱いたい場合は OpenID Connect を使い、OAuth 2.0 だけで「ログイン」を自作しないのが安全です。