「Googleでログイン」の中身を見てみた（OpenID Connect）
身近な認証 - Googleでログイン
最近、各サービスで新しいアカウントを作成してパスワードをちゃんとメモして...ってこと、なくなりましたね。それは今でもできますが、多くの場合、ログイン画面に行くと下のような画面が出てきて、「Continue with Google」というありがたいオプションがあるので、これを使ってGoogleアカウントで色々なサービスにログインしていると思います。
このおかげでサービスごとにいちいちパスワードを覚えたり、という面倒な作業がなくなったと思います。
では実際、この中身は何がどう動いているのか？というのを見てみようというのがこの記事の目的です。
OpenID Connectとは
OpenID Connectは、OAuth2.0と呼ばれる認可フレームワークを認証フレームワークに拡張したSSOを実現するJSON形式の標準規格です。OASISにより2014年に策定された比較的新しい規格です。
SAMLでのXML形式と比べ、JSON形式を採用したJWT（JSON Web Token）は非常に軽量であること、またメタデータを事前に共有する必要がないことから、近年様々なところでこのOpenID Connectが使われるようになっています。
今回はそのOpenID Connectの仕組みについて紹介します。
OpenID Connectのフロー
OpenID Connectの認証フローは図の通りです。登場人物としては、
- あるサービスプロバイダーにログインしたいユーザー
- クライアントアプリ。ChatGPTを提供しているOpenAIだったり、あらゆるSAAS。
- ユーザーの認証を担当しているOpenID プロバイダ。今回はGmailでのログインのためGmail。
の3人です。
ユーザーはクライアントアプリにGmailでのログイン要求をすると、受け取ったクライアントアプリは、
とユーザーをリダイレクトでOpenID プロバイダに飛ばし、OpenID プロバイダに対するIDトークン要求を出します。これは身元（ID）を確認してくださいという要求です。
それを受け取ったOpenID プロバイダは、
とユーザーに対してログイン画面を表示し、ユーザーID・パスワード・場合によっては2段階認証などを用いてユーザーを認証します。
ユーザーが認証を通過した場合、OpenID プロバイダは先ほどのクライアントアプリに対してIDトークンを作成し、作成したIDトークンを送ります。これは要は、
というような情報です。このIDトークンは署名付き（OpenID プロバイダの秘密鍵での署名）で、受け取ったクライアントアプリはその署名が適切か（本当に依頼したOpenID プロバイダから来たものなのか）を検証します。
この時、SAMLなどでは事前にこの署名に用いた公開鍵やハッシュ関数などはメタデータとしてSP（サービスプロバイダー）とIdP（アイデンティティプロバイダー）とで交換しますが、OpenID ConnectではJWKS（JSON Web Key Set）として各OpenID プロバイダが公開している情報から入手してきます。
したがって事前に共有しておく必要がありません。
この検証が通ったら、クライアントアプリはIDトークンで受け取ったユーザー情報をもとに、そのユーザーに対応するアカウントにアクセス許可を渡し、これによってユーザーはサービスにログインすることができます。
以上がOpenID Connectによる認証の流れです。
OpenID Connectの一例
では、実際に「Googleでサインイン」の中身を見てみましょう。
使用したツールは、Google Chromeの開発者ツールです。Chrome上で、右クリック→検証で開くツールですね。ここのネットワークタブで、「ログを保持」というボタンを有効にしておけば、リダイレクトなどが起きてもログをそのまま保持してくれます。
では、実際にこの機能を使ってChatGPTに「Googleでログイン」をしてみましょう。
これによってログを見ることができます。
各自確かめてみてください。
最後
今回はOpenID Connectによる認証の仕組みと中身について見てみました。
こんな形でいつも使っている「Googleでサインイン」が実現されているのですね。
Discussion