ソーシャルログインの危険性は？事業者が設計で防ぐ7つのリスクと対策

リスクはなくならず、SNSアカウントの側へ移る

ソーシャルログインを入れると、次のリスクは確かに小さくなります。

• 自社でパスワードを保管しないため、パスワードが漏えいしない
• 他のサイトから漏れたパスワードを使い回した不正ログインの対象にならない

その代わり、ログインの安全性がSNSアカウントの管理に左右されるようになります。とはいえ、危険性の多くは事業者の設計で小さくできます。7つのリスクと主な対策は次の表のとおりです。

ソーシャルログインで移るリスク

1. SNSアカウントの乗っ取り

利用者のSNSアカウントが乗っ取られると、そのSNSでログインしている自社サイトにも入られます。事業者の側では、不正にログインされても大きな被害につながらないよう、次の対策をしておきましょう。

乗っ取られたときの備え

• 重要な操作前の本人確認：住所変更・支払い登録・ポイント利用の前に
• ログインや変更を通知：登録済みの連絡先へ知らせる
• 多要素認証を案内：利用者にSNS側での設定を勧める

• 住所の変更、支払い方法の登録、ポイントの利用など、重要な操作の前に追加の本人確認を行う
• ログインや登録内容の変更を、登録済みの連絡先に通知する
• 利用者には、SNS側で多要素認証を設定するよう案内する

2. メールアドレスでの誤った統合

SNSから受け取ったメールアドレスが既存会員と一致したとき、自動的に同じ会員として統合すると、他人の会員情報にログインされる恐れがあります。メールアドレスの確認が不十分なSNSで、第三者が他人のアドレスを使ってアカウントを作っていた場合です。

既存会員との紐づけ方

防ぐには、既存会員との紐づけを、その会員としてログインしている本人にだけ行うようにしましょう。具体的な手順はアカウント統合の設計で解説しています。

3. 過剰な情報の要求

必要以上の情報を求めると、利用者が許可画面で不安を感じて離脱する原因になります。また、SNSの審査で、取得する情報がサービスの内容に対して過剰だと判断されることもあります。

求める情報の絞り方

• 必要最小限だけ求める：許可画面での離脱と審査での指摘を防ぐ
• 使い道をボタン近くに：受け取る情報と使い道を短く書く
• ポリシーに利用目的：内容は法務・管理部門に確認する

求める情報は必要な範囲に絞り、使い道もはっきり示しておきましょう。

• サービスに必要な最小限の情報だけを求める
• ログインボタンの近くに、受け取る情報と使い道を短く書く
• 利用目的をプライバシーポリシーに記載し、内容を自社の法務・管理部門に確認する

SNSごとに取得できる情報はソーシャルログインで取得できる情報にまとめています。

4. 実装の不備によるなりすまし

SNSから受け取った本人の証明（IDトークン）を検証しない、リクエストの一致を確かめるstateパラメータを省く、といった実装の不備は、なりすましの経路になります。

省いてはいけない検証

• IDトークンを検証：署名・発行元・宛先・有効期限を確認
• stateの一致を確認：送った値と戻った値を照合する
• ライブラリの設定を確認：検証が有効になっているか確かめる

IDトークンの署名・発行元・宛先・有効期限の検証と、stateの一致の確認は、どちらも省かずに行う必要があります。自社で実装する場合は実績のあるライブラリを使い、検証が有効になっているかまで確認しておきましょう。詳しくはソーシャルログインの仕組みとセキュリティで解説しています。

5. SNSが使えなくなる

利用者がSNSアカウントを削除した、凍結された、SNS側で障害が起きている、といった場合、そのSNSではログインできません。

SNSが使えないときの備え

• 2つ目のログイン手段：メール・別のSNS・パスキーなど
• 設定し直す手順：メールアドレスでの本人確認など
• 別の手段へ案内：エラー画面で終わらせない
• 本人確認の強さを調整：簡単すぎる復旧は不正ログインの入口に

ログイン手段が1つしかないと、利用者はそのままログインできなくなります。次のような備えが必要です。

• メールアドレスでのログイン、別のSNS、パスキーなど、2つ目のログイン手段を用意する（パスキーとは）
• メールアドレスでの本人確認などで、ログイン手段を設定し直せる手順を用意する
• エラー画面で終わらせず、別の手段への案内を表示する

ただし、復旧の手順が簡単すぎると、そこが不正ログインの入口になります。本人確認をどこまで厳しくするかは、会員情報の重要度に合わせて決めましょう。

6. アプリ内ブラウザで入れない

LINEやInstagramなどのアプリ内でリンクを開くと、アプリ内ブラウザで表示されます。Googleはアプリ内ブラウザからのログインを制限しており、そのままではログインできない場合があります。この制限に気付かないと、SNS経由で訪れた利用者がまとめてログインできなくなります。

アプリ内ブラウザかどうかを判定し、標準のブラウザで開くよう案内を表示しましょう。この確認はテストの項目にも入れておくとよいでしょう（ソーシャルログインの導入手順と期間）。

7. 受け取った情報の保持

SNSから受け取った情報を必要以上に長く、広く持つほど、漏えいしたときの影響が大きくなります。保存する範囲と期間は、次のように決めておきましょう。

• 保存する項目を決め、使わない情報は保存しない
• 退会した会員の情報と、SNSとの紐づけを削除する
• 認証サービスを使う場合は、サービス側にデータが残る期間と場所を確認する

利用者の不安にどう答えるか

「危ないのでは」という不安から、ソーシャルログインを避ける利用者もいます。よくある不安と答え方は次のとおりです。

こうした答えをログイン画面の近くやFAQに短く書いておくと、ソーシャルログインを避ける利用者を減らせます。

よくある質問

ソーシャルログインとパスワードのログインは、どちらが安全ですか？

リスクの種類が違うため、単純には比べられません。パスワードの漏えいや使い回しのリスクはソーシャルログインのほうが小さく、SNSアカウントの管理に左右される点はソーシャルログイン特有のリスクです。重要な操作に本人確認を追加し、ログイン手段を複数用意すれば、両方の弱点を補えます。

ソーシャルログインを使わないほうがよいケースはありますか？

社員が使う業務システムのように、アカウントを組織で管理する必要がある場合は、私用のSNSアカウントでのログインは向きません（ソーシャルログインとSSO・IDaaSの違い）。

パスキーのほうが安全ですか？

パスキーはフィッシングに強く、パスワードを使わない方式です。ソーシャルログインとは解決する問題が違うため、併用が現実的です（パスキー導入の進め方）。

Login Plus について

Login Plusは、6つのソーシャルログイン（Apple・Facebook・Google・X（旧Twitter）・Yahoo! JAPAN・LINE）とパスキーに1つの実装で対応できるサービスです。

• トークンの検証と、各SNSの仕様変更への追随はLogin Plus側で担当
• Login Plusが仲介した個人データは、取得から1時間で自動削除
• パスキー（FIDO2 / WebAuthn）にも対応し、2つ目のログイン手段として併用できる
• 複数のSNSを1つの会員IDに紐づけ可能

データの扱いについてはセキュリティのページもご覧ください。