フロー
そもそもOAuth2.0は「認可」のための仕組みであって、「認証」のための仕組みではない。
認可:特定のデータへのアクセス、操作を許可する認証:ユーザーを確認する（ログイン）
図中①〜④のみがOAuth2.0で定義される部分であり、①〜④の各リクエストそれぞれのパラメータも定義されている。それぞれのパラメータの詳細についてはここを参照。
| 項目 | 解説 |
|---|---|
クライアントIDの取得 | 前もってクライアントのアクセス権などをリソースサーバーに登録し、クライアントIDを受け取っておく。このクライアントIDは①で送信する。 |
①認可コード要求 | 認可コードを要求。 |
ユーザーによる認可 | ここでユーザーの承諾を得る。例えばgithubはログイン画面を表示し、ユーザー名とパスワードを要求（認証）した後、認可するリソースを確認または選択する。 |
②認可コード発行 | 認可コードを発行。 |
③アクセストークン要求 | アクセストークンを要求。 |
④アクセストークン発行 | アクセストークンを発行。 |
アクセストークンによる通信 | アクセストークンを用いて許可されたリソースにアクセスする。 |
補足
エンドユーザーは正確にはResource Ownerと呼ばれ、リソースサーバーは正確にはAuthorization Server(認可サーバー)、Resource Serverに分離される(参考)- OAuth2.0では
Authorization ServerとResource Serverの間の通信については定義されない（あくまで①〜④のみ） - 実用上この２つは一つのサーバーで行うことが多い
クライアントを含めたこの4つはロールと呼ばれる
- OAuth2.0では
- 実はアクセストークン発行までのフローには他にも複数の方法があり、上記の方法が最も複雑である
アクセストークンと認可コードが分離されているのは認可コードを用いる以外にも認可を取得する方法が定義されているためである認可コードによる認可（上図）、インプリシットグラント、リソースオーナーパスワードクレデンシャルグラント、クライアントクレデンシャルグラントが定義される(総称して認可グラントという)
| 名前 | 解説 |
|---|---|
認可コードによる認可 | 上図 |
インプリシットグラント | 認可コードを挟まず、直接アクセストークンを発行する（①→④） |
リソースオーナーパスワードクレデンシャルグラント | ユーザーによる認可の際のログイン画面がクライアントによって提供される（認可コードはなく、直接アクセストークンを発行する） |
クライアントクレデンシャルグラント | ユーザーの許可を求めず、ログインに相当する処理をクライアントが直接行う（認可コードはなく、直接アクセストークンを発行する） |
アクセストークンの発行とともにリフレッシュトークンの発行を受けることがあるアクセストークンの有効期限が切れたら、リフレッシュトークンを送信することで、新たにアクセストークンの発行を受けられる- 特定の
認可グラントに依存しない
OAuth2.0とは
アクセストークンの発行手順に関する仕様である