OpenID Providerを作る）まずは全体像から

こんにちは、富士榮です。

前回のポストに書いた通り、OpenID Providerを作っていきましょう。

なお、今回は一番オーソドックスなところから、ということで認可コードフロー（Authorization code flow）をベースに考えていきたいと思います。ちなみにOpenID Connect Core 1.0の仕様はOpenIDファウンデーションジャパンの翻訳・教育WGが日本語化していますので必要に応じて参照していきたいと思います。

まずは全体のイメージをおさらいしておきたいと思います。

下図が認可コードフローの全体シーケンスです。よく見るやつですね。なお、そもそも論となりますがOpenID Connectの究極の目標は「Relying PartyがIDトークンを取得すること」です。その過程においてユーザ認証を行なったり、APIアクセスするためのアクセストークンを取得することもありますが、まずは周辺の仕様を削ぎ落としてど真ん中だけを考えることが理解を進めるためには必要だと思います。

シーケンスは大きくは4つのフェーズで構成されますが、実際の認可コードフローのコアとなるのは２番目、３番目のフェーズです。

各フェーズでやっていることは以下の通りです。

1. ディスカバリ
• OpenID Providerが提供している機能やエンドポイントなどの情報をRelying Partyに提供する（ディスカバリエンドポイントを通してメタデータを提供する）
2. 認可※OpenID ConnectのベースとなるOAuth2.0を踏襲するため認可と呼称されるが仕様上は認証リクエスト・レスポンス（Authentication Request/Response）
• 認可コードをRelying Partyに提供する（認可エンドポイント）
3. トークン発行
• 認可コードを受け取りIDトークンをRelying Partyに提供する（トークンエンドポイント）
4. ユーザ情報提供
• ユーザ情報をRelying Partyへ提供する（userInfoエンドポイント）
• OAuth文脈において認可サーバから見ると保護対象リソースとなるためアクセストークンを使って認可される

次回からそれぞれのフェーズについてgithubに公開したコードをベースに解説していきたいと思います。