はじめに
これから何回かに分けてOAuth2.0の認可サーバに対する理解を深めるためのまとめを行います。
まとめの目的は、OAuth2.0の認可サーバー（authorization server）を作ることです。
OAuth2.0についてはこれまで何人もの先人達がまとめてるかと思いますが、RFCを参考にしながら自分流にまとめていきたいと思います。
動作理解編の目的
OAuth2.0の認可サーバーはどのような仕事をしているのか言葉ベースでまとめていきたいと思います。
OAuth2.0内で使用する実際のパラメータ名を使用した詳細な動作はフロー編で行なっていきたいと思います。
そもそもOAuth2.0とは？
OAuth2.0のプロバイダについてまとめる前に、まずはOAuth2.0について簡単にまとめます。
OAuth2.0とはRFC6749で定義されるHTTPプロトコル上で使用する認可フレームワークです。
以下、RFC6749のAbstractの引用
The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf. This
specification replaces and obsoletes the OAuth 1.0 protocol described
in RFC 5849.
つまりは、あるアプリケーション内で別サービス内の情報を利用する際に、公開するリソースとそれに対する操作（閲覧・作成・更新・削除など）を双方（あるアプリケーションと別サービス）が共有するための仕組みです。
例：私のGithubアカウントのリポジトリ閲覧権限を、あなたが作成するアプリケーション内で使用させてあげる。
OAuth2.0の登場人物
OAuth2.0に登場する要素は以下のとおりです。
わかりやすいように上の例と照らし合わせて書いていきます。
| 登場する要素 | 例との照らし合わせ |
|---|---|
| リソースオーナー | 私 |
| クライアント | あなたが作成するアプリケーション |
| 認可サーバー | GitHubの認証・認可機能 |
| リソースサーバー | GitHubのAPIサーバー機能 |
わかり辛いのはクライアントには様々なパターンがあることです。
- Webブラウザベースのアプリケーション
- Webアプリケーションのアプリケーションサーバ
- クライアントにインストールするアプリケーション（PC、スマートフォンアプリ）
- etc...
と、ここまでOAuth2.0に登場する要素まで説明しましたが、
今回は作成したいOAuth2.0の認可サーバーに特化してまとめていきたいと思います。
OAuth2.0の認可サーバーとは？
OAuth2.0の認可サーバーとは、リソースオーナーの本人認証と、リソースに対するアクセス許可（認可）を行い、リソースオーナーと許可したアクセス情報を一意に特定することができるアクセストークンをクライアントに発行するサーバです。
ここで発行されたアクセストークンをリソースサーバへのリクエスト時に合わせて送出することで、リソースサーバ側でアクセストークンの検証を行い、リクエストが正規のものかを判別することができます。
以下、RFC6749内のauthorization serverを引用
The server issuing access tokens to the client after successfully
authenticating the resource owner and obtaining authorization.
世の中の認可サーバー
大手のサービスではOAuth2.0の認可サーバーがたくさん稼働しています。
だいたいはOpenID ConnectというOAuth2.0上で実装されるユーザ認証の仕組みに使用されていることが多いですが、それについては後で別でまとめようと思います。
よく見るOAuth2.0認可サーバー
- Microsoft
- GitHub
- etc...
認可サーバーの仕事
認可サーバーには以下の仕事があります。
プログラムとして実装する際は、以下の１レコードがそれぞれユースケースになるイメージです。
| アクション | アクセス者 | 詳細 |
|---|---|---|
| ユーザー認証 | リソースオーナー | リソースオーナーに対して、認可サーバー上でのユーザー認証。基本的にはログイン画面を表示して認証させることが多い。RFCの中では認証方法については範囲外としている。 |
| リソース認可 | リソースオーナー | リソースオーナーに対して、リソースサーバー上のリソースへの認可を行うためのインターフェースの提供。 |
| アクセストークンの発行 | クライアント | クライアントアプリケーションに対してアクセストークンの発行を行う。 |
| リフレッシュトークンの発行 | クライアント | クライアントアプリケーションに対してリフレッシュトークンの発行を行う。 |
| アクセストークンの無効化 | リソースオーナー | 流出したアクセストークンを即座に無効化するためのユーザーインターフェースを提供する。 |
| リフレッシュトークンの無効化 | リソースオーナー | 流出したリフレッシュトークンを即座に無効化するためのユーザーインターフェースを提供する。 |
| アクセストークンの検証 | リソースサーバー | クライアントアプリケーションから送られたアクセストークンを検証する。 |
動作理解編のまとめ
今回はOAuth2.0の認可サーバーを作成するにあたって、どのような動作をしているのか理解するのに重きを置きました。
次回：フロー編
RFC6749にて定義されているフローについて、認可サーバーから見た時に具体的にどのようなパラメータに対してどのような処理をするのかを書こうと思います。
今後の予定
- 動作理解編 <- 今回ここ
- フロー編 <- 次ここ
- セキュリティ編
- 設計編
- 実装編
おまけ：OAuth2.0の認可サーバー実装
自分だけのOAuth2.0認可サーバーを構築したい場合は以下のOSSを使うと楽ちんです。
自分で作るのは理解を深めるため（もとい自己満足）がとても強いです。
- Keycloak
- OpenAM