ソーシャルログインの仕組みとセキュリティ｜実装前に押さえる設計

仕組み：認証はSNS側で完結する

ソーシャルログインは OAuth 2.0 と OpenID Connect の上で動きます。名前が似ていますが役割が違います。

• OAuth 2.0……「このアプリに、あなたの情報へのアクセスを許可しますか」という認可の仕組み
• OpenID Connect……OAuth 2.0 の上に載り、「この人は誰か」を伝える認証の仕組み

ログインに使うのは後者です。OAuth 2.0 だけでは「情報にアクセスしてよい」ことしか分からず、本人確認の根拠にはなりません。 ここを混同した実装は、なりすましの余地を残します。

処理の流れ

1. ユーザーがログインボタンを押す
2. SNS側の認可画面へ遷移し、渡す情報の範囲に同意する
3. SNSが認可コードを返す
4. サービスのサーバーが、そのコードをSNSのサーバーに渡し、IDトークンと交換する
5. IDトークンを検証し、含まれる識別子で会員を特定する

重要なのは4番目がサーバー間で行われることです。ブラウザ上だけで完結させる実装では、トークンを差し替えられる余地が生まれます。

実装で押さえる4点

1. IDトークンを必ず検証する

受け取ったIDトークンをそのまま信用してはいけません。署名・発行元・宛先・有効期限を検証します。

検証を省くと、攻撃者が別のサービス向けに発行されたトークンを持ち込んで、他人になりすませる可能性があります。ライブラリを使う場合も、検証が有効になっているかを確認してください。

2. 会員の識別子にメールアドレスを使わない

もっとも多い設計ミスです。メールアドレスはユーザーが変更できます。 識別子に使うと、変更された時点で別人として扱われ、会員データが分裂します。

各SNSが発行するソーシャルID（一意な識別子）で識別してください。メールアドレスは「連絡先」として保持します。

3. 確認済みメールアドレスかを見る

取得したメールアドレスには「確認済みかどうか」の情報が付いてくる場合があります。これを見ずに既存会員と突き合わせると、他人のアドレスを名乗って既存アカウントを乗っ取られる余地が生まれます。

4. CSRF対策（state パラメータ）

認可のリクエストに state を付け、戻ってきたときに一致を確認します。これを省くと、攻撃者のアカウントを被害者に紐づけさせる攻撃が成立します。 実装の要点として見落とされやすい箇所です。

「安全になる」わけではない

ソーシャルログインを入れると、次の点は確かに改善します。

• 自社でパスワードを保管しなくて済む（保管しないものは漏えいしない）
• パスワードの使い回しによるリスト型攻撃の対象にならない
• 大手SNSの多要素認証を、そのまま自社サービスの防御として使える

一方で、新しく生まれるリスクもあります。

• SNSアカウントが乗っ取られると、自社サービスも入られる
• SNS側の障害中はログインできない
• 実装の検証を怠ると、なりすましの経路になる

「導入すれば安全になる」という説明は正確ではありません。 リスクの所在が、自社のパスワード管理からSNSアカウントの管理へ移る、という理解が実態に近いものです。

見落とされやすい設計上の論点

アプリ内ブラウザで動くか

LINEやInstagramの投稿からリンクを開くと、通常のブラウザではなくアプリ内ブラウザで表示されます。ここで認証が動かないと、その流入経路をまるごと失います。 テスト項目に入れてください。

複数のSNSを1つの会員に紐づけるか

同じ人がGoogleとLINEの両方でログインした場合、別会員として扱うか、1つにまとめるかを決めておきます。まとめる設計は後から入れるのが難しくなります。

連携解除された後

ユーザーがSNS側で連携を解除した場合、次のログインは失敗します。エラー画面で終わらせず、別の手段で入れる導線を用意してください。

取得した情報の更新

SNS側で氏名やプロフィール画像が変更されても、自動では反映されません。ログインのたびに最新を取得するか、初回のみ取得して以降は自社で管理するかを決めます。

自社実装か、サービス利用か

ここまでの論点はSNSごとに個別に発生します。 1つ目は自社実装でも現実的ですが、2つ目以降で判断が変わります。

判断の分かれ目は「保守を続けられるか」です。初期開発だけを比べると自社実装が安く見えますが、担当者が異動した後も追随できる体制があるかで選んでください。

よくある質問

SNSのパスワードは自社に渡りますか？

渡りません。認証はSNS側で完結し、サービスが受け取るのは本人であることの証明と、ユーザーが同意した範囲の情報だけです。

OAuth と OpenID Connect のどちらを使えばよいですか？

ログイン（本人確認）に使うなら OpenID Connect です。OAuth 2.0 だけでは「情報へのアクセス許可」しか得られず、本人確認の根拠になりません。

パスキーとどちらを入れるべきですか？

解決する問題が違うため、併用が前提です。パスキーはパスワードの置き換え、ソーシャルログインはアカウント発行そのものの省略です。

Login Plus について

Login Plusは、6つのIDプロバイダ（Apple・Facebook・Google・X・Yahoo! JAPAN・LINE）とパスキーに1つの実装で対応できるサービスです。

• トークンの検証や仕様変更への追随はLogin Plus側で担当
• 取得できる情報の違いを吸収し、統一された形で受け取れる
• 複数のSNSを1つの会員IDに紐づけ可能
• 実装手順書・サンプルコードを提供