今回は「OpenID Connect」についてまとめます。
ただ、OpenID Connect 自体は広範囲にわたるユースケースをカバーしている難解な仕様です。 すべて取り上げると無駄が多い感じがしたので、一番サポート率が高く使われるであろうユースケース「BasicOP」についてまとめていきます。
何ができるのか
OpenID Connect は「あるサービスで利用している ID や メールアドレス などの情報を自分のサイトでも利用できるようにするエコな仕組み」です。 すでに OpenID Connect を組み込んだサイトはあるのでなんとなくイメージは出来ていると思います。
どうやって実現するのか（OpenID Connect 全体像）
ではそんな「他サイトに登録されたID情報を自サイトへもってくる仕組み」がどのようなものか概要を見ていきましょう。
登場人物について
まず登場人物についてみていきます。 それぞれ次のような役割をもった登場人物になります。
- エンドユーザー
- 実際にサービスを利用するユーザーのこと。
- クライアント
- OpenID Connect で ID を利用したいサービス提供事業者。 Webサーバーだったりスマホアプリだったり。
- 認可サーバー
- OpenID Connect で ID を公開・提供するサービス。 特にエンドユーザーの認証認可およびクライアントに対するトークン発行を行うサーバー。 認可サーバーとリソースサーバーは別に表記されるが同じサーバーの場合もある。
- リソースサーバー
- OpenID Connect で ID を公開・提供するサービス。 特にリソース情報（ID や メールアドレス、個人のプロフィールなど）を公開するサーバー。 認可サーバーとリソースサーバーは別に表記されるが同じサーバーの場合もある。
処理フローについて
では、前述の登場人物がどのように処理していくかの大まかな流れを見ていきます。
-
利用アカウント選択画面
エンドユーザーがクライアントに接続すると大抵はOpenID Connect の 選択画面（Google や Facebook などの選択画面） が表示されます。
-
ログイン画面 & ログイン
エンドユーザーがいずれかの OpenID を利用するよう選択すると、当該 OpenID 提供事業者の認可エンドポイントに遷移（例えば Google のログイン画面へ遷移）します。 画面遷移した先で未ログインであればログイン（例えば Google の ID/PASSWORD でログイン）を行い、クライアントに対して個人情報を展開してよいかの確認画面が表示されます。
-
リダイレクト with 認可コード
エンドユーザーがクライアントに対する情報開示を許可すると、認可サーバーは「認可コード」を発行してあらかじめ指定されたクライアント画面へリダイレクトします。
-
トークンリクエスト with 認可コード
クライアントはリダイレクト元（＝認可サーバー）から受け取った情報から「認可コード」を取り出します。 クライアントは「認可コード」を認可サーバーの「トークンエンドポイント」に向かって送信し、「IDトークン（= ID情報）」と「アクセストークン」を取得します。
-
個人情報リクエスト with アクセストークン
クライアントはリソースサーバーに対して「アクセストークン」を送信します。 リソースサーバーは要求された追加の個人情報を応答します。
OAuth 2.0 と OpenID Connect 1.0 の違い
よく「OAuth 2.0」と「OpenID Connect 1.0」が混ぜて話されている気がしますが… 両者は「OpenID Connect が OAuth をベースに足りない仕様をたしたもの」という関係になります。 図で描くと以下のような感じでしょうか。
OAuth 2.0 の仕組みに対してIDまわりの仕組み、具体的には「IDトークン」と「個人情報API（リソースサーバーに対して個人情報を取得依頼する仕組み）」を足したものが OpenID Connect です。
今回は「OpenID Connect」の中でも一番使われそうなユースケースにしぼってまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！
最後に… このブログに興味を持っていただけた方は、 ぜひ 「Facebookページ に いいね！」または 「Twitter の フォロー」 お願いします！！