ソーシャルログインの仕組み｜OAuth 2.0とOpenID Connectの違い、PKCE・IDトークンまで

ソーシャルログインの仕組みは、OAuth 2.0 という「許可を渡す」ための規格と、その上に載った OpenID Connect という「本人であることを伝える」ための規格でできています。自社サイトはSNSからパスワードを受け取らず、SNSが署名した「IDトークン」を確かめることで、利用者が誰かを知ります。

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

ソーシャルログインの基本はソーシャルログインとはで解説しました。本記事では一段深く、裏側でやり取りされている情報と、実装で必ず確かめるべき点を説明します。

押さえるべき点は3つです。

1. ログインの根拠はIDトークン……OAuth 2.0 のアクセストークンは「情報を見てよい許可証」で、本人であることの証明ではない
2. 認可コードフローとPKCEを使う……トークンをブラウザのURLに直接載せる古い方式は使わない
3. state・nonce・署名を必ず検証する……省くと、他人になりすましたログインを許す恐れがある

登場する3者と、2つの規格の違い

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

2つの規格は、答えている問いが違います。

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

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

IDトークンには、宛先（aud）として自社サイトのクライアントIDが書かれ、SNSの署名が付いています。宛先と署名を確かめれば、「自社サイトのために、このSNSが、この人を確認した」ことが分かります。これがログインに OpenID Connect を使う理由です。

認可コードフローの流れ（図にするときの7ステップ）

ソーシャルログインで標準的に使われるのが認可コードフローです。ボタンを押してからログインが終わるまでを、図にできる形で示します。

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

ポイントは、トークンそのものはブラウザを通らず、サーバー同士で受け渡すことです。ブラウザを通るのは、すぐに期限が切れて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 を知らないため、トークンに交換できません。もともとはスマートフォンアプリ向けに作られた仕組みですが、RFC 9700 では、クライアントシークレットを安全に保管できないアプリには必須、サーバーで動くWebサイトにも推奨とされています。SNSが対応していれば、Webサイトでも付けておくのが現在の考え方です。

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

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

これらに加えて、署名が正しいかを確かめます。署名の確認には、SNSが公開している鍵やクライアントシークレットを使います。LINEのように、検証用のAPIを用意しているSNSもあります。

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

state と nonce の違い

どちらも「ランダムな値を送り、戻ってきた値と比べる」仕組みで、混同されがちです。守っているものが違います。

どちらもログインのたびに新しく作り、利用者のセッションに結びつけて保存します。固定の値や、推測できる値では意味がありません。

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

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

よくある質問

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

受け取りません。パスワードはSNSの画面で入力され、自社サイトに届くのは認可コードとトークンだけです。そのため、自社で利用者のSNSのパスワードを保管する必要はありません。

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

ログインに使うなら、OpenID Connect に対応しているかを確認してください。OAuth 2.0 だけの場合、アクセストークンでプロフィールを取得して利用者を特定する実装になり、宛先の確認などを自社で補う必要があります。SNSによって対応状況が違うため、各SNSの開発者向け文書で確かめてください。

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

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

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の内訳を確認

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