OAuth2.0の認可サーバーを理解する〜フロー編①〜

はじめに

この記事は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）
それについてはセキュリティ編で触れていきたいと思います。

認可コード処理フローのメリット・デメリット

メリット

1. 利用者はユーザーエージェント（ブラウザ）上の操作のみで連携処理が行える
2. ユーザーエージェントにアクセストークンを保持する必要が無いため、セキュリティが高い
3. 安全に情報が保持できるため、有効期間が長いリフレッシュトークンを使っていても安心

デメリット

1. クライアントの認証情報を秘匿に扱えるクライアントでなければ使用できない（一部除く）
2. 基本的にはリソースオーナーがリアルタイムで認証情報を入力する必要がある

認可コード処理フローにおける認可サーバーの仕事

ここまではOAuth自体の説明でしたが、この記事の目的である認可サーバーの動作について触れていきたいと思います。

認可サーバーが用意するエンドポイントとしてRFC6479で定義されている「認可エンドポイント」「トークンエンドポイント」に加えて、RFC6749では仕様の範囲外としている「リソースオーナーの認証エンドポイント」を含めた以下3つのエンドポイントを実装する必要があります。

1. 認可エンドポイント
2. リソースオーナー認証エンドポイント
3. トークンエンドポイント

それでは各エンドポイントについて、簡単に処理内容をまとめていきたいと思います。

認可エンドポイント

1. リクエスト内容がRFC6749の「4.1.1. 認可リクエスト」に沿っているか精査を行う
2. 精査結果が正しい場合はログイン画面をユーザーエージェントに返却する
3. 精査結果が正しいくない場合はエラーを返却する

リソースオーナー認証エンドポイント

1. 認証情報が正しいか精査を行う
2. 認証情報が正しい場合はユーザーエージェントに「redirect_uri」で指定されたURIへのリダイレクト命令を返却する
3. 認証情報が正しくない場合は再度認証画面を表示する

トークンエンドポイント

1. リクエスト内容がRFC6749の「4.1.3. アクセストークンリクエスト」に沿っているか精査を行う
2. 精査結果が正しい場合はアクセストークン・リフレッシュトークンを返却する
3. 精査結果が正しくない場合はエラーレンスポンスを返却する

まとめ

• アクセストークンを取得するフローは基本的に４つ
• 認可コード処理フローはOAuth2.0の中でも基本的なフロー
• 認可サーバーでは３つのエンドポイントを実装する必要がある

次の記事では残り３つのフローについて触れていきたいと思います。