ソーシャルログインの仕組み｜ボタンを押してからログイン完了までの流れと注意点

ボタンを押してからログインが終わるまでの流れ

利用者から見たソーシャルログインは、SNSの画面にいったん移って許可をし、元のサイトに戻ってくるだけの操作です。その間に何が起きているのかを、順に見ていきます。

1. 利用者が「Googleでログイン」「LINEでログイン」などのボタンを押すと、画面がSNSのページに切り替わります。このときサービスは、どのサービスからの依頼か、どの情報を受け取りたいかをSNSに伝えています。
2. SNSにまだログインしていなければ、利用者はSNSのIDとパスワードを入力します。入力する先はSNSの画面なので、パスワードがサービス側に届くことはありません。すでにSNSにログインしている状態なら、この入力は省かれます。
3. SNSが「このサービスに氏名やメールアドレスを渡してよいか」を確かめる画面を表示し、利用者が許可します。
4. 許可されると、画面は元のサービスに戻ります。このときSNSからは、許可されたことを示す一度きりの引換券のようなもの（認可コード）が一緒に届きます。
5. サービスはその引換券を、利用者のブラウザを通さずにSNSへ直接送り、本人であることの証明（IDトークン）と、許可された範囲の情報を受け取ります。
6. サービスは証明が本物かどうかを確かめ、中に含まれる利用者ごとの番号（ソーシャルID）で会員を探します。見つかればログインが完了し、見つからなければ新しい会員として登録するのが一般的です。

利用者が操作するのはボタンを押すことと許可することだけで、それ以外のやり取りはサービスとSNSの間で進みます。

サービスが受け取る情報

SNSから届くのは、利用者ごとに決まったソーシャルIDと、利用者が許可した範囲の氏名・メールアドレス・プロフィール画像などです。受け取れる情報の種類はSNSによって異なり、パスワードが含まれることはありません。

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

この流れは、OAuth 2.0 と OpenID Connect という2つの仕組みの上で動いています。名前は似ていますが、役割は別物です。

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

ログインに使うのは OpenID Connect のほうです。OAuth 2.0 だけで分かるのは「情報にアクセスしてよい」ことまでで、本人確認の根拠にはなりません。両者を混同した実装は、なりすましの余地を残します。2つの違いはOAuth 2.0 と OpenID Connect の違いを解説した記事で詳しく説明しています。

裏側で行われている処理

先ほどの流れを、技術の用語で書き直すと次のようになります。

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

このうち4番目の交換は、ブラウザを経由せずサーバー同士で行います。ブラウザ上だけで完結させる実装では、途中でトークンを差し替えられる余地が生まれるためです。

実装で塞いでおく、なりすましと乗っ取りの経路

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

受け取ったIDトークンはそのまま信用せず、署名、発行元、宛先、有効期限を確かめてから使います。

検証を省くと、攻撃者が別のサービス向けに発行されたトークンを持ち込み、他人になりすませる可能性があります。ライブラリに任せている場合も、検証の設定が有効になっているかは一度確かめておきましょう。

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

設計でつまずきやすいのがこの点です。メールアドレスはユーザーが自分で変更できるため、識別子に使うと変更した時点で別人として扱われ、会員データが分裂します。

会員の識別には、各SNSが発行するソーシャルID（一意な識別子）を使いましょう。メールアドレスは連絡先として別に保持しておけば足ります。

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

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

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

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

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

導入によって改善するのは、次の点です。

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

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

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

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

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

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

LINEやInstagramの投稿からリンクを開くと、ページは通常のブラウザでなくアプリ内ブラウザで表示されます。ここで認証が動かなければ、その流入経路から来たユーザーは誰もログインできないため、テスト項目に入れておく必要があります。

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

同じ人がGoogleとLINEの両方でログインしたとき、別の会員として扱うのか、1つにまとめるのかを決めておきます。後からまとめるのは難しいため、最初に方針を決めておきましょう。

連携解除された後

ユーザーがSNS側で連携を解除すると、保存していたアクセストークンは使えなくなります。次回のログインではSNSの許可画面が改めて表示され、許可されれば同じ固有IDが返るのが通常です。トークンが無効になったときはエラーで止めてしまわず、もう一度許可を求める流れにしてください。

取得した情報の更新

SNS側で氏名やプロフィール画像を変更しても、自社サービスには自動で反映されません。ログインのたびに最新の情報を取得するのか、初回だけ取得して以降は自社で管理するのかも、事前に決めておく必要があります。

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

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

判断の分かれ目は、保守を続けられるかどうかです。初期開発だけを比べると、自社実装のほうが安く見えます。担当者が異動した後も各SNSの変更に追随できる体制があるかどうかで考えると、選び方を誤りにくくなります。

よくある質問

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

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

2回目以降のログインでも、SNSの許可画面は表示されますか？

一度許可していれば、通常は表示されず、ボタンを押すだけで元のサイトに戻ります。ただし、利用者がSNS側で連携を解除した場合は、次回のログインで許可画面が改めて表示されます。

ソーシャルログインで会員登録も同時に済みますか？

初回のログインで該当する会員が見つからなければ、SNSから受け取った情報をもとに会員を作成する設計が一般的です。登録に使えるのは、利用者が許可した範囲の情報に限られます。

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

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

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

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

Login Plus について

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

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