TL;DR
サードパーティのアプリケーションが、HTTP サービスへの限られたアクセス権を得るための認可フレームワーク。IETF の RFC 6749 で定められている。
なぜ必要か
RFC 6749 によると、従来のクライアント・サーバ型の認証では、サードパーティのアプリケーションがリソースオーナーの認証情報（パスワード）を保存する必要があった。この方法には次の問題がある。
- サードパーティに必要以上に広いアクセス権を与えてしまう
- パスワードを変えない限り、特定のサードパーティだけのアクセスを取り消せない
- どれか 1 つのサードパーティが侵害されると、ユーザのパスワードとデータが漏れる
仕組み
OAuth 2.0 には 4 つのロールがある。
- リソースオーナー: 保護されたリソースへのアクセスを許可できる主体
- リソースサーバ: 保護されたリソースを持つサーバ
- クライアント: リソースオーナーの代わりにリソースを要求するアプリケーション
- 認可サーバ: リソースオーナーを認証したあと、クライアントにアクセストークンを発行するサーバ
アクセストークンは、クライアントに与えられた認可を表す文字列である。クライアントはまずリソースオーナーに許可を求め、認可グラントを受け取る。そのグラントを認可サーバに示してアクセストークンを受け取り、トークンを使ってリソースサーバにリソースを要求する。
認可グラントには、認可コード、インプリシット、リソースオーナーのパスワード認証情報、クライアント認証情報の 4 種類がある。
注意点
OAuth 2.0 は認可のための仕組みである。認証を扱うには、拡張プロトコルの OpenID Connect を使う。