ソーシャルログインのOAuth 2.0とOpenID Connectの違い

OAuth 2.0は、利用者の情報へのアクセスを自社サイトに「許可する」ための規格です。ログインに必要な「いま操作しているのは誰か」を伝えるのは、その上に作られたOpenID Connectです。

ログインに使うのはOpenID Connect。OAuth 2.0だけでは足りない

ソーシャルログインの基本はソーシャルログインとはで、会員登録が終わるまでの全体の流れはソーシャルログインの仕組みで解説しています。

実装で外せないのは次の点です。

1. ログインの根拠にはIDトークンを使いましょう。アクセストークンは「情報を見てよい許可証」で、本人であることの証明にはなりません。
2. 認可コードフローとPKCEを使いましょう。
3. state・nonce・署名は必ず検証してください。検証を省くと、他人になりすましたログインを許す恐れがあります。

登場する3者と、OAuth 2.0とOpenID Connectの違い

ソーシャルログインに登場するのは次の3者で、規格の文書ではそれぞれ独特の呼び名が使われます。

2つの規格は、目的が違います。

アクセストークンをログインの根拠にしてはいけない理由

アクセストークンは「持っている者に情報を見せてよい」という許可証です。誰に宛てて発行されたかを自社サイトでは確かめにくいため、別のサイト向けのアクセストークンを持ち込まれても見分けられない場合があります。

一方、IDトークンには、宛先（aud）として自社サイトのクライアントIDが書かれ、SNSの署名が付いています。宛先と署名を確かめれば「自社サイトのために、このSNSが、この人を確認した」ことが分かる点が、アクセストークンとの違いです。

ボタンを押してからログインが終わるまで（認可コードフロー）

ソーシャルログインで標準的に使われるのは認可コードフローで、自社サイト・ブラウザ・SNSの間で次のやり取りが起きます。

1. 利用者がログインボタンを押すと、自社サイトはstate・nonce・code_verifierをランダムに作り、セッションに保存します。
2. 利用者のブラウザを、URLにclient_id・redirect_uri・scope=openid …・state・nonce・code_challengeを付けてSNSの認可画面へ移動させます。
3. 利用者はSNSにログインし、情報の提供に同意します。パスワードを入力するのはSNSの画面なので、自社サイトには届きません。
4. SNSはブラウザをコールバックURLに戻し、短時間だけ有効な「認可コード」とstateを自社サイトに渡します。
5. 届いたstateが手順1で保存した値と一致するかを、自社サイトで確かめます。
6. 自社サイトのサーバーからSNSへ直接、認可コードとcode_verifier、クライアントの認証情報を送り、IDトークンとアクセストークンを受け取ります。
7. IDトークンを検証し、中のsub（利用者のID）で会員を探します。見つからなければ新しく作ります。

トークンが受け渡されるのは手順6だけで、手順6はブラウザを通らないサーバー同士の通信です。ブラウザを通るのは、すぐに期限が切れて1回しか使えない認可コードだけです。

かつて使われた「インプリシットフロー」のように、アクセストークンを認可レスポンスでブラウザのURLに載せて返す方式は、OAuth 2.0のセキュリティのベストプラクティス（RFC 9700）で使うべきでないとされています。

PKCEで認可コードを盗まれても使えなくする

PKCE（ピクシー、RFC 7636）は、認可コードの横取りを防ぐ仕組みです。

• 自社サイトは、43〜128文字のランダムな文字列（code_verifier）を作り、手元に保存する
• それをSHA-256で変換した値（code_challenge）だけを、最初の認可リクエストで送る（方式はS256）
• トークンを受け取るときに元のcode_verifierを送り、SNSは変換結果が最初の値と一致するかを確かめる

途中で認可コードを盗んだ者はcode_verifierを知らないため、トークンに交換できません。PKCEはもともとスマートフォンアプリ向けに作られましたが、RFC 9700では、クライアントシークレットを安全に保管できないアプリには必須、サーバーで動くWebサイトにも推奨とされています。

IDトークンの中身と、確かめる項目

IDトークンはJWT（JSON Web Token）という形式の文字列で、ヘッダー・中身・署名がピリオドでつながっています。中身には、次のような項目（クレーム）が入っています。

あわせて、SNSが公開している鍵やクライアントシークレットを使って、署名が正しいかどうかも確かめる必要があります。LINEのように、検証用のAPIを用意しているSNSもあります。

会員の照合にはsubを使ってください。メールアドレスは利用者が変更でき、SNSによっては転送用のアドレスが渡されるため、照合には向きません（Appleでサインインの注意点）。

スコープの指定と、プロフィール情報の受け取り方

OAuth 2.0では、受け取りたい情報の範囲を「スコープ」で指定し、SNSの同意画面にはその範囲が表示されます。OpenID Connectではスコープにopenidを必ず含め、そのうえで必要な分だけ標準のスコープを足すのが一般的です。

• profileを足すと、名前やプロフィール画像などを受け取れる
• emailを足すと、メールアドレスと、それが確認済みかどうかを受け取れる

使えるスコープの名前や受け取れる項目はSNSごとに違うので、各SNSの開発者向け文書で確認してください。

名前やメールアドレスがIDトークンに入っていない場合は、一緒に受け取ったアクセストークンでSNSのUserInfoエンドポイントを呼び出して取得します。UserInfoの応答にもsubが入っているので、IDトークンのsubと一致することを確かめてから使いましょう。

stateとnonceの違い

stateとnonceは、どちらもランダムな値を送って戻ってきた値と比べる仕組みなので混同されがちですが、防ぐ攻撃が異なります。

stateとnonceはログインのたびに新しく作り、利用者のセッションに結びつけて保存してください。固定の値や推測できる値を使うと、攻撃を防げません。

よくある実装ミスとセキュリティ上の注意

SNSアカウントの乗っ取りなど、実装以外のリスクと対策はソーシャルログインの危険性と対策で、LINEを例にした具体的な設定の流れはLINEログインの実装手順で解説しています。

よくある質問

ソーシャルログインで、自社サイトは利用者のパスワードを受け取りますか？

受け取りません。パスワードはSNSの画面で入力され、自社サイトに届くのは認可コードとトークンだけです。

「OAuth認証」という呼び方は正しいですか？

よく使われる呼び方ですが、OAuth 2.0そのものは認可のための規格で、利用者が誰かを確かめる手順は定めていません。ソーシャルログインで「OAuth」と呼ばれているものの多くは、実際にはOpenID Connectか、OAuth 2.0にSNS独自の方法で本人確認を足したものです。

OAuth 2.0に対応していれば、ソーシャルログインに使えますか？

ログインに使うなら、OpenID Connectに対応しているかを確認してください。OAuth 2.0だけの場合は、アクセストークンでプロフィールを取得して利用者を特定することになり、宛先の確認などを自社で補う必要があります。

PKCEを使えばstateは不要ですか？

RFC 9700では、PKCE・OpenID Connectのnonce・stateのいずれかでCSRFを防ぐことが求められ、PKCEはその手段の1つとされています。ただ、stateを必須にしているSNSもあるので、両方を使っておくのが確実です。

IDトークンとアクセストークンは保存しておくべきですか？

ログインの確認が終われば、IDトークンを保存しておく必要は通常ありません。ログイン後もSNSのAPIを呼ぶ場合だけ、アクセストークンをサーバー側で安全に保管してください。

Login Plus について

Login Plusは、6つのソーシャルログイン（Apple・Facebook・Google・X（旧Twitter）・Yahoo! JAPAN・LINE）とパスキーに、1つの実装で対応できるサービスです。SNSごとに異なる認可リクエストやトークンの扱いを個別に実装する代わりに、Login Plusとの連携を1つ実装し、ログイン後の利用者情報はuserinfo APIで受け取ります。

• 各SNSの仕様変更にはLogin Plus側で対応
• 各SNSへの申請手順書を、契約企業に無償で提供
• FIDO2 / WebAuthnに基づくパスキーにも対応
• 管理画面で、利用ID数・ログイン数・利用SNSの内訳を確認

自社のシステムにどう組み込むか、技術的なご相談は、資料請求またはお問い合わせからどうぞ。