はじめに

この記事はOAuth2.0の認可サーバーを理解することを目的にしています。
前回の動作理解編に引き続き、OAuth2.0のフローについてまとめていきたいと思います。

動作理解編
フロー編 ← 今回ここ
セキュリティ編
設計編
実装編

OAuth2.0の認可フロー

OAuth2.0の認可サーバーの主な仕事はリソースオーナーの認証・認可の後にアクセストークンをクライアントアプリケーションに渡すことです。
今回説明する**「フロー」は、アクセストークンをクライアントに渡すために用意された複数の手順（フロー）です。
RFC6749では「4.Obtaining Authorization（認可の取得）」**として記述されている箇所になります。説明するフローは以下の４つです。

認可コード処理フロー → ①で説明
インプリシットグラントフロー → ②で説明
リソースオーナーパスワードクレデンシャルフロー → ②で説明
クライアントクレデンシャルフロー → ②で説明

それではこの記事では認可コード処理フローについて見ていきたいと思います。

認可コード処理フロー

認可コード処理フローはOAuth2.0の最も基本的なフローです。
認可コード処理フローを用いたアクセストークン取得までのシーケンス図は以下のとおりです。

認可コード処理フローの概要

認可コード処理フローでは、認可サーバーから直接ユーザーエージェントにアクセストークンを発行するのではなく、**認可コード（authorization_code）**というアクセストークンとの引き換えチケットを発行します。
この認可コード（authorization_code）と、クライアントの認証情報（client_id、client_secret）を提示できた場合にアクセストークンおよびリフレッシュトークンを発行します。

認可コードフローではクライアントの認証情報（client_secret）を秘匿にする必要があり、これを秘匿にできないJavaScriptのみで完結したアプリケーションではclient_secretを用いた認可コードフローは使用できません。

ただし、本来**パブリッククライアント（ブラウザベースのJavaScriptアプリケーション等）**向けに用意されたインプリシットグラントフローが、アクセストークン傍受にかかる攻撃を受けやすいことから、それに対応するべく認証情報を秘匿に保てない場合でも認可コードフローが行える仕組みもあります。（RFC7636）
それについてはセキュリティ編で触れていきたいと思います。