OpenID ConnectとOAuth2.0について簡単に説明してみる
背景
認証機能をどう実装するのか？ログイン機能をどう実装するのか？WEBサービスやアプリの開発者は、新しいサービスを開発し始める時に、こういった課題にほぼ必ずと言っていいほど直面する（Web3の文脈ではその限りではないが）。自前でメールアドレス・パスワードログインを実装するにしても、正しくパスワード管理をしないと大惨事になりかねないし、ソーシャルログイン（Facebookログイン等）の要件も後から追加されるかもしれない。認証周りの機能はセキュリティとUX両方に著しく影響を与えるので非常に重要である。たしかに、Firebase Authenticationのように認証周りの機能一式を簡単に実装するためのツールも増えてきており、開発コストも下がってきているのも事実である。ただ、そうしたツールを通じてOAuth2.0やOpenID Connectを利用していても、実はOAuth2.0やOpenID Connectを正しく理解できていないというケースも多いだろう。今回の記事では、認証周りの仕組みをより理解したい人（特に非技術者）に向けて、認証周りでもっとも利用されているOAuth2.0とOpenID Connectの仕組みについて解説する。
OAuth2.0ってそもそも何？
OpenID Connectについて触れる前にまずOAuth2.0について少し見ていく。TwitterやFacebookのようにユーザ自身が情報を追加していくようなサービスが増えていくに連れ、異なるサービス間でのID共有やセッションの連携が求められるようになった。例えば、自分のサービスがFacebookの友達情報を参照したい、といった具合だ。この場合、ユーザはFacebookのログイン情報そのもの（メールアドレスとパスワード等）はそのサービスに渡すことなく、Facebookの必要な情報へのアクセス権限のみを共有するべきである。このようにログイン情報を渡すことなく権限だけを上手く共有する仕組み（プロトコル）がOAuthである。OAuthは2007年に策定されたが、2009年に脆弱性が見つかりOAuth2.0へと進化した。OAuth1とOAuth2は互換性がなく、今ではOAuth2.0が基本的には利用される。技術的には、このように権限を渡すことを「認可」という。OAuth2.0は認可をセキュアに行うためのプロトコルなのである。
では、堅苦しい説明は置いておいて、OAuth2.0のフローについて以下の例えで見ていく。
株式会社ABCは、株式会社XYZが保管しているAliceの書類を参照したいとする。
イメージとしては株式会社ABCが会員登録を処理する時に外部の信用できる機関（株式会社XYZ）から本人確認書類を要求しているような感じである。
- 株式会社ABCはAliceに、株式会社XYZにアカウントを持っているか尋ねる。
- Aliceは「YES」と答える。
- 株式会社ABCは「であれば、株式会社XYZで保管してある君の書類が欲しいんだけど、 書類の保管先の鍵 をくれないかな？」とAliceに尋ねる。
- Aliceはその鍵を取得するべく株式会社XYZに赴く。
- 株式会社XYZの窓口で、Aliceは身元の確認をして、株式会社ABCに対して 書類の保管先の鍵 を作るように申請する。
- 株式会社XYZの窓口は後日、「例の鍵が完成したから取りに来てな」という手紙を株式会社ABCに郵送する。
- 株式会社ABCの社員はその手紙を持って、株式会社XYZの窓口まで行き、株式会社ABCの社員であることを伝え、その手紙を交換に、Aliceの鍵を受け取る。厳密には鍵単体というよりは、「Aliceの書類保管先」の鍵がついたキーホルダーのイメージ。
- 株式会社ABCの社員がその鍵を持って、株式会社XYZの書類保管先に行き、保管先から鍵を使って、Aliceに関する書類を取り出す。
- 株式会社ABCの社員はその場でその書類を印刷して帰る。株式会社ABCは無事Aliceの書類を株式会社XYZから取得完了。
この時、 Aliceはそもそも鍵なんか作らずに、書類のコピーを申請して、株式会社ABCに鍵ではなく書類のコピーをそのまま渡せばいいのではないか？ と思ったかもしれないが、それはまさしくOpenID Connectの出番である。こちらについては後述する。
書類保管先の鍵 を発行することで、たとえ書類が更新されてもAliceは特に何もすることなく、株式会社ABCは最新の書類を簡単に参照できる（その社員がまた株式会社XYZに行けば良いだけ）。また、もし、株式会社ABCがその書類を更新したい場合は、鍵があることで株式会社XYZ内のオリジナルの書類を更新することができる。この鍵は厳密にはキーホルダーのようになっており、Aliceが指定した場所に入れる鍵が入っている。もし、Aliceが書類を5つの場所に分けて保管している場合は、5つの保管先につながる鍵がくっついているのである。
ここで出てきた登場人物と実際の用語を確認していく。
| 登場人物 | 実際の用語 |
|---|---|
| 株式会社ABC | Client |
| 株式会社XYZの書類保管先 | Resource server |
| Alice | Resource owner |
| 株式会社XYZの窓口 | Authorization server |
| 株式会社がXYZの窓口が郵送した手紙 | Authorization code |
| 株式会社XYZの窓口で株式会社ABCの社員が本当にABCの社員であることを証明する時に利用する身元確認情報 | Client secret |
| 株式会社ABCがもらった鍵の集まり（キーホルダー） | Access token |
| キーホルダーに入っている個々の鍵 | Scope |
| 書類 | Resource |
| ステップ6を明示的に行い鍵は対面でしか渡さないフロー | Authorization code flow |
| ステップ6をスキップしていきなり鍵を郵送するフロー | Implicit flow |
| 株式会社XYZからの郵送 | Redirect URI |
OAuthの濫用
OAuth2.0は非常に有用なプロトコルだが、冷静に鍵を渡す行為は危険 でもある。もし、株式会社ABCが悪意のある組織で、Aliceの銀行口座へのアクセス権をAliceにお願いして、Aliceが何も考えずに鍵の申請をしてしまった場合は、Aliceの銀行口座からお金を取られてしまう可能性すらあるのだ。しかも、Aliceのリソースを利用するために鍵が必要というよりは、Aliceの情報が欲しいだけ、というケースも多く、OAuth2.0は認可（e.g., Aliceの権限管理）のプロトコルであるにも関わらず、認証（e.g., Aliceの身元確認）でも利用されることが非常に多くなってしまった のである。
OpenID Connectとは
こういう事態に対して、OAuth2.0を拡張して認証も標準に組み込んだのがOpenID Connect（以下OIDC） である。
3. 株式会社ABCは「であれば、株式会社XYZで保管してある君の書類が欲しいんだけど、書類の保管先の鍵をくれないかな？」とAliceに尋ねる。
OpenID Connectでは、先ほどのOAuth2.0のステップ３において、 書類保管先の鍵 ではなく、 書類のコピー を選択肢にも追加したのである。ここで 書類のコピー を指定すると、
6. 株式会社XYZの窓口は後日、「鍵が完成したから取りに来てな」という手紙を株式会社ABCに郵送する。
先ほどのステップ６において、 書類のコピー が届くようになるのである。 もし株式会社ABCが欲しいのは、Aliceの身元が確認できる情報だけなのであれば、この 書類のコピー さえ手に入れば残りのステップは実行する必要がなくなる。 書類保管先の鍵 もわざわざ発行しなくて良くなるのだ。 もちろんこの 書類のコピー には発行元が確認できるように株式会社XYZの署名がしてある。この 書類のコピー のことを ID Token と呼び、このように ID TokenをOAuth2.0に導入することで認証も標準化したのがOIDC である。もちろんこの 書類のコピー と同時に 書類保管先の鍵 の生成も同時に行えるし、鍵の生成フローはOAuth2.0と同じである。
ステップ３の株式会社ABCからの要求のことを認可リクエストといい、実際にはAliceではなく、Authorization server（株式会社XYZの窓口）に直接リクエストが行く。認可リクエストにて、Client（株式会社ABC）は様々な設定をする。Implicit flowなのかAuthorization code flowなのか（郵送で 書類のコピー を渡すのか、対面で 書類のコピー を渡すのか）、利用したいスコープ（キーホルダーについてくる個々の鍵）の選択、実際にAuthorization serverがClientに情報を送る時の方式は何なのか（郵送の具体的な方式）、等の細かい設定を行う。
まとめ
このように、本来アクセストークンの生成やアクセストークンを通じた権限の移譲を標準化したOAuth2.0をもとにして、ID Tokenも扱えるようにしたのがOIDCなわけである。OIDCは他の認証、認可のプロトコルに比べてよりセキュアかつよりシンプルで利用している組織も多く、2022年時点では認証認可に関してはもっとも利用されているプロトコルである。
Discussion