人々の日常生活やビジネスシーンにおいて、ソーシャルメディアは必要不可欠なものとなりました。誰もが手元のスクリーンをついつい見続けてしまうのは、よくデザインされたUI/UX、ユーザの趣味嗜好や閲覧傾向を反映したレコメンドアルゴリズム、長すぎず短すぎない絶妙な長さのコンテンツ、他人や知り合いの動向が気になってしまう人間心理など、要因は実にさまざまです。

技術的な観点では、ソーシャルログインの登場がソーシャルメディア間のログイン障壁を取り払い、情報を発信する側とコンテンツを視聴する側の双方にとって、極めて利便性の高い、シームレスな環境を作り上げている点が挙げられます。

サービスごとにログインをし直さなくても、Xに投稿したコンテンツがInstagramにも反映され、飲食店の検索サイトでお店を探したら、Xのアカウントでログインし、そのまま予約まで完了できるといった具合です。

今回は、ソーシャルログインの仕組みとそこに潜む個人情報漏洩のリスク、実装が進むWebサイトと比較して、あまり充分とは言えないソーシャルログインにおけるユーザの同意取得の実態、大切な個人情報を意図せず自ら外部に共有しないようにするために、ポイントとなってくるアクセス権限管理の重要性などについて、見ていきたいと思います。

ソーシャルログインの登場

ソーシャルログインは、「シングルサインオン（SSO）」という技術で実装されています。「企業の社内システムにSSOを導入し、アカウント管理とセキュリティレベルを強化する」などの文脈でもよく耳にする用語ですが、実は異なる企業が運営しているはずのソーシャルメディア間のログイン連携においても、同様の仕組みが用いられています。

そのソーシャルログインが初めて世の中に登場したのは、2008年頃となっています。

ソーシャルログインの歴史と進化

2008年：　Facebook Connect の登場

Facebookが「Facebook Connect」を公開。これにより、外部のWebサイトやアプリが「Facebookアカウントでログイン」できるようになりました。これが、現在の「ソーシャルログイン」の原型と言えます。

2009～2011年：　他のSNSも追随

ログインフォームを作らなくていい、ユーザはすぐにサービスを利用できる、これらの利便性により、ブログ、SNS、ECサイト、ゲーム、予約サイトなどで一気に利用が広まりました。

・Google：2010年頃に「Googleアカウントでログイン」を正式サポート。

・X：OAuth認証で「Twitterでログイン」機能を導入。

・LinkedIn、Yahoo!、Microsoftアカウントなども同様のソーシャルログインを提供開始。

2014年：　Facebookが「Login Review」制度を導入

ソーシャルログインの急速な広まりにより、ソーシャルログインを利用しているWebサイトやアプリが、ユーザの個人情報を過剰に収集しているとの懸念と批判が次第に高まります。

特にFacebookは、「名前・プロフィール写真・友達リスト」などにアクセス可能な仕様となっており、かつサービスそのものが実名での利用を原則としていることから、Facebook内の個人情報が外部のWebサイトやアプリにソーシャルログインを通じて共有される仕様について、セキュリティリスクとプライバシーに関する懸念が以前から指摘されていました。

そこで、Facebookは「ソーシャルログインを利用するサービスの開発者は、アクセスしたいデータ項目ごとに審査を受ける必要がある」とし、利用者情報の保護を強化したGraph API v2.0をリリース、批判への対応を図りました。

しかし、Graph API 1.0で実装されている既存のWebサイトやアプリには2年間の置き換え宥恕期間があり、ほどなくして、当時世界最大級の個人情報流出事件（ケンブリッジ・アナリティカ事件）が発覚します。この頃から、事業者による個人情報や個人データの活用は、法制度で厳しく規制される世界的な潮流への転換点を迎えました。

2018年：　GDPR施行、ユーザの同意が必須に

EUでGDPRが施行され、「ユーザの明示的な同意取得」が事業者の義務となりました。違反した場合には高額な制裁金が課される可能性があり、事業者に義務の履行と法令遵守を強くに迫る法制度が世界的に広まります。これに対応して、ソーシャルログインを提供するSNS各社は、「ログイン時に表示される情報」や「許可する範囲」を細かく指定できるUIの提供を開始しました。

2019年：　Appleの「Sign in with Apple」が登場

Appleがセキュリティとプライバシーの両方に配慮したソーシャルログインをリリース。匿名化されたメールアドレスを発行し、ソーシャルログインを使用するWebサイトやアプリ側にユーザの実際のメールアドレスを共有しない仕様になっています。ユーザの追跡は行わない、二要素認証を必須とするなど、安全性と利便性を兼ね備えた設計が特徴となっています。

2025年～：　ソーシャルログインの現在地

現在、ユーザには、Google、Apple、Meta（Facebook）、LINE、X、Microsoftなど複数の選択肢があります。特にスマホアプリでは、初回起動時に「SNSログイン or メール登録」
と表示され、ユーザに選択させるUI設計が事実上の標準仕様になっています。

その一方で、この表示が本当に意味しているところ、両者の本質的な違い、許可した結果として将来起こる可能性があること、などをよく理解しないまま、利用開始を優先し「なんとなく同意」してしまう危険性や子どもや高齢者などの弱者を如何に保護するかが課題となっています。

【関連記事】個人情報保護法に影響あり？子どものSNS利用に関する各国の法規制の動向

まとめ

ソーシャルログインは、ユーザを煩わしいログインプロセスから解放したことで登場からわずか数年間で爆発的に普及しましたが、同時にソーシャルログインの使用にあたり、不要で過剰なアクセス権限を要求してくるWebサイトやアプリの存在が問題視されるようになりました。

今では、多くの利用者が「無料であること、便利であること」にはその代償があることを理解しています。ソーシャルログインは「便利さ」と「危うさ」が隣り合わせの仕組みです。

利用者として、ログインしようとしているサービスがどの国のどのような事業者が提供しているものなのか十分注意を払うとともに、ソーシャルログインを提供するSNS各社の動向や社会の評価、関連する法制度にも関心を向け、正しい情報と知識に基づいて、責任を持って判断できるようにしたいところです。

ソーシャルログインの仕組み

ソーシャルログインはどのように実現されているのでしょうか？次にその仕組みの概要を一緒に見てみましょう。

ソーシャルログインは多くの場合、主にOAuth 2.0 と OpenID Connect (OIDC) をベースとしたシングルサインオン（SSO）の仕組みを使って実装されています。これらは、ログインにおける認証（OpenID Connect）と認可（OAuth 2.0）を外部のソーシャルメディアとやり取りするための標準プロトコルです。

認証（Authentification）

認証は、ユーザが誰であるかを確認するプロセスです。一般的には、ユーザ名とパスワードを使用して行います。認証の目的は、システムがユーザの身元を確認し、正当なアクセス権を持つ人物であることを確かめることです。認証には、知識情報（パスワード、秘密の質問など）、所持情報（ワンタイムパスワード、マイナカード、運転免許証など）、生体情報（指紋、顔、静脈など）の3つの要素があり、これらを複数使用した認証を多要素認証といいます。

認可（Authorization）

認可は、認証されたユーザがどのリソースや機能にアクセスできるかを決定するプロセスです。認可は、ユーザが特定のデータやアプリケーション機能にアクセスする権限を持っているか、いないかを確認し、その権限付与を決定します。例えば、あるユーザがファイルを閲覧できるが、編集はできないといった制限を設けることができます。

ソーシャルログインの流れ（概要）

主な登場人物

・ユーザ：利用者本人、ログインを試みる人
・クライアント：利用者がアクセスし、ログインしようとしているWebサイトやアプリ
・認可サーバ（SNS）：ソーシャルログインを提供しているSNS（Google, Facebook, Xなど）
・リソースサーバ：ユーザ情報（名前、メールアドレスなど）を保持しているSNS側のAPI

ソーシャルログインの流れ　※Googleを例にしています。

[1] ユーザがログインしようとしているWebサイトで「Googleでログイン」ボタンをクリック
↓
[2] クライアント（Webサイトやアプリ）が、Googleの認可サーバに認証リクエストを送信
– client_id（アプリID）
– redirect_uri（戻り先URL）
– scope（要求する情報：openid、email、profile など）
– response_type=code
↓
[3] Googleがログイン画面を表示（同意取得画面を含む）
– ユーザが情報共有に「同意」
↓
[4] Googleが「認可コード（authorization code）」を redirect_uri に付けてクライアント（Webサイトやアプリ）に返す
↓
[5] クライアント（Webサイトやアプリ）が認可コードを使い認可サーバ（トークンエンドポイント）にアクセス
– access_token（APIアクセス用）
– id_token（ユーザの認証情報、署名付きのトークン）
↓
[6] クライアント（Webサイトやアプリ）がid_tokenを検証し、ユーザ情報を取得、適宜リソースサーバにアクセスし許可された情報を追加で取得、ログイン成功

各トークンの役割

・ID Token：ユーザの認証情報を含むトークン。ユーザが誰であるかをクライアント（Webサイトやアプリ）に伝える。ユーザの名前、メールアドレスなどのプロファイル情報が含まれる。

・Access Token：ユーザが認証された後、クライアント（Webサイトやアプリ）がリソースサーバにアクセスする際に使うトークン。ユーザ情報や権限を含む。ユーザが許可したデータや機能に一定時間アクセスが可能。

まとめ

ソーシャルログインを導入している多くのWebサイトやアプリでは、ログインの認証と認可のプロセスで、単純な認証を提供するだけではなく、ユーザ情報の収集と連携を同時に行っています。ここで問題になってくるのが、「不必要なアクセス権限を過剰に要求するWebサイトやアプリ」の存在です。

世界各国でプライバシー関連法が施行され、広がりを見せる中、多くの法令で個人情報の収集や保管、外部サービスへの連携に際しては、「ユーザの同意取得が必要」としています。この規則は当然のことながら、Webサイトやアプリがソーシャルログインを利用する際に行っている個人情報の収集と連携においても適用されます。

ソーシャルログインで連携される可能性がある情報とは？

それではソーシャルログインに際して、どのようなアクセス情報が連携される可能性があるのか、GoogleとFacebookの同意画面を例にして、もう少し深堀りして見てみましょう。

ソーシャルログインの同意画面で表示される項目の概要

ソーシャルログインの同意取得画面では、以下のような項目が表示されます。ユーザは個々の項目の内容を確認し、同意の可否について意思表示を求められます。　※アプリを例にしています。

①アプリ名と開発者情報：ユーザがどのアプリにアクセスを許可するかを明確に示します。
②プライバシーポリシーへのリンク：アプリのデータ取扱い方針を確認できます。
③要求されるスコープ（アクセス権限）：アプリがアクセスを求めるユーザ情報の範囲（スコープ）が表示されます。範囲は自由に定義できます。

Googleのソーシャルログイン： 同意画面の構成と要求される情報の例

・openid：ユーザのIDを識別するための基本的な情報
・email：ユーザのメールアドレス
・profile：ユーザの名前やプロフィール写真など

Facebookのソーシャルログイン： 同意画面の構成と要求される情報の例

・public_profile：ユーザの公開プロフィール情報
・email：ユーザのメールアドレス
・user_friends：ユーザの友達リスト
・user_birthday：ユーザの誕生日

スコープで定義できる項目　※Googleを例にしています。

スコープの項目では、どの範囲のアクセス権限をユーザに要求するかを自由に定義することができます。ソーシャルログインの認証認可のプロセスで使用されるアクセストークン（Access Token）を使って、scope=email profile openid のように取得したい情報の範囲を定義します。

・openid：OpenID Connectを使用してログイン（ID Tokenを返す）
・email：メールアドレス
・profile：氏名、性別、プロフィール画像など
・userinfo.profile：プロファイル情報
・calendar：Googleカレンダー
・contacts.readonly：連絡先（名前、メールアドレス、電話番号、住所など）
・drive：Googleドライブ
・photolibrary.readonly：フォトライブラリ

スコープでは非常に広範囲な情報へのアクセス許可が実装可能であることが分かります。

安易に許可する前によく確認することが重要

同意画面で表示される情報は、クライアント（Webサイトやアプリ）が要求するスコープやパーミッション（アクセス許可）に基づいています。一度アクセスを許可すると、クライアント（Webサイトやアプリ）はその情報を取得し利用することが可能になり、同意した項目の情報はクライアント（Webサイトやアプリ）に連携されることになります。

ここで注意したいのは、同意した内容によっては、連絡先や友達リストなど、時には本人ではない第三者の個人情報が含まれてしまう点にあります。

アプリでは、ユーザは、後からアカウント設定でアプリに付与したアクセス権限を確認し、同意を撤回することができますが、一度、外部のサービスに共有されてしまった連絡先や友達リストなどの情報は、アクセス権限の撤回だけでは取消すことができない可能性があるため、事業者にデータの削除を求めるなど、別の手段で対応する必要が出てきます。

どの項目のどこまでの情報にアクセス権限を許可するのか、安易に同意をする前に慎重に各項目の内容を確認し、検討しましょう。また、同意取得画面で表示されるWebサイトやアプリのプライバシーポリシーをよく確認し、各Webサイトやアプリのデータの取扱い方針についても、十分に理解することが大切です。

【関連記事】プライバシーポリシーと個人情報保護方針に違いはある？目的や記載内容を解説！

個人情報を意図しない共有から守るために

今回は、ソーシャルログインを実現する仕組み、シングルサインオン（SSO）とそのログインプロセスにおいて、ユーザが気づかないうちに外部のWebサイトやアプリに個人情報を共有してしまう危険性があることについて見てきました。

ソーシャルログインは、ログインの認証と認可を与えるだけの必要最小限の便利な仕組みであるはずが、現実にはWebサイトやアプリの事業者の実装次第でサービスに不要なスコープを追加でき、過剰なアクセス権限の要求の温床になっています。

ソーシャルログインは、ユーザのIDとパスワード管理の手間を省いてくれる非常に便利な機能です。しかしながら、認証認可の機能をサービス提供のためだけではなく、個人情報を収集する仕組みとして活用するWebサイトやアプリが存在しているのもまた事実です。

許可が必要な項目だけ書かれていて何に使うのかが説明されていない、そもそも許可をしないと次に進めない仕様になっているため許可せざるを得ないなど、ユーザからの同意取得にまつわる数多くの課題や問題点が指摘されているのが現状です。

気づかないうちに自身や大切な家族や友人の個人情報を外部に共有しないためにも、ソーシャルログインの利用に際しては、不必要なアクセス権限の許可を要求されていないか？その情報を外部のWebサイトやアプリを提供している事業者に共有してしまって本当に問題はないのか？一人ひとりが充分に注意を払うことが望まれます。

時には、いさぎよく諦めてソーシャルログインを選択しないという判断もまた大切です。

RTmetricsは、個人情報やプライバシーの保護、ユーザの同意に基づく法令を遵守したデータ活用とマーケティングを推進する企業を応援しています。
是非、ご検討下さい。