Web アプリケーション向けの 認可（Authorization） フレームワーク。RFC 6749 / 6750 （2012 年 10 月）。ユーザーがパスワードを第三者サービスに渡さずに API への委任アクセスを認める仕組みを標準化した。
概要
OAuth 1.0 （2007 年）の 「リクエスト署名が必須で実装が難しい」 という弱点を解消するため、 TLS を必須にすることで署名を不要化 したのが OAuth 2.0。これによりエコシステムが爆発的に拡大し、Facebook ログイン・Google ログイン・GitHub OAuth 等のソーシャルログインのほぼすべてが OAuth 2.0 をベースとしている。
重要な誤解：認証ではなく「認可」
| 仕様 | 役割 |
|---|---|
| OAuth 2.0 | 認可（Authorization）— 「この API を叩いてよい」 |
| OpenID Connect | 認証（Authentication）— 「この人は誰だ」 |
OAuth 2.0 のアクセストークンは 「この API を叩く権利を持つ何か」 を表すが、 「誰が叩いているか」は保証しない 。認証目的に流用すると Confused Deputy 攻撃などの脆弱性を招くため、認証が必要なら OpenID Connect を併用するのが現代の正解。
主な Grant Type
| フロー | 用途 |
|---|---|
| Authorization Code | サーバーサイド Web アプリ。最も推奨 |
| Authorization Code + PKCE | SPA・モバイル。 OAuth 2.1 で全クライアント必須 |
| Client Credentials | サーバー間通信（マシン間認証） |
| Refresh Token | アクセストークン更新 |
| OAuth 2.1 で廃止 | |
| OAuth 2.1 で廃止 |
構成要素
- Resource Owner — リソースの所有者（通常はエンドユーザー）
- Client — リソースにアクセスしたいアプリケーション
- Authorization Server — 認可コード・トークンを発行するサーバー
- Resource Server — 保護されたリソース（API）を提供するサーバー
関連用語
- OpenID Connect — OAuth 2.0 上の認証層
- PKCE — 認可コード横取り対策の必須拡張
- ID Token — OIDC が発行する認証情報
- AWS Cognito — OAuth 2.0 / OIDC をネイティブ実装