学習記録「OAuth 2.0 Authorization Code Grant」
概要
OAuth 2.0 Authorization Code Grant を用いた認可サーバー開発を担当することになったため、学習した。備忘録としてブログに残す。
Authorization Code grant以外のフローについては触れません。 脚注しているQiita記事がすごくわかりやすかった。
OAuth
OAuthが必要とされる背景
OAuthとは、Webサービス間でリソース(ユーザーデータなど)への「アクセス権限の認可」を行うための仕組みを指す。
OAuthが必要とされる背景として、Web連携を行うサービスが増加し、それぞれのAPIを公開して共有するようになったことから、悪意のあるアプリからリソースを守るためのAPIアクセスを認可する手段が必要となったことが挙げられる。
登場人物
リソースサーバー：ユーザーのデータを管理するサーバー
API：クライアントアプリ-リソースサーバーでユーザのデータををやり取りする口
クライアントアプリ：ユーザーのデータを利用したいアプリ
悪意のあるアプリ：ユーザーのデータを悪用しようとするアプリ
OAuthとは
APIを守る仕組みとして、あらかじめクライアントアプリに「アクセストークン」(クライアントアプリがリソースを利用することを許可されていると示すもの)を持たせておくことがベストプラクティスとされている。このアクセストークンは、認可サーバーと呼ばれるサーバーによって発行される(リソースサーバーがこの役割を兼務することもある)。
OAuthとは、このアクセストークンの発行をクライアントアプリが認可サーバーに対して要求し、認可サーバーが応答する仕組みを標準化したものを指す。
登場人物(続き)
ユーザ：クライアントアプリを利用する人
認可サーバー：アクセストークンを発行するサーバー
このアクセストークンを発行するフローは、RFC 6749 (The OAuth 2.0 Authorization Framework) で4 つ定義されている。次節で説明するAuthorization Code Grantはそのうちの一つ。
Authorization Code Grant
「認可サーバー」に認可リクエストを送り、応答として「認可コード」を受け取り、その認可コードをアクセストークンと交換するフロー。「ユーザー」のブラウザを使用して認可画面を表示し、認可サーバーからクライアントに認可を委譲する。以下シーケンス図もどき。
