Prompt
Googleなどの認証プロバイダが、サービス提供者に与えるユーザーの情報の範囲は？
やっほー！GoogleやGitHub、Microsoftなどの認証プロバイダ（IdP: Identity Provider）を使った「ソーシャルログイン」、便利だよね！
情報工学を学ぶ君なら、裏側で OAuth 2.0 や OpenID Connect (OIDC) が動いていることは知っているはず。この時、サービス提供者（RP: Relying Party）に渡される情報の範囲は、実は 「スコープ（Scope）」 という概念によって厳密に制御されているんだ。
「どこまで見られているのか？」という疑問を、技術的なレイヤーで解剖していこう！
1. 最小単位：プロフィールの基本情報
ほとんどのサービスが要求するのは、OpenID Connectで定義されている標準的なスコープだよ。
-
openid (必須): 「このユーザーは認証されました」という証（IDトークン）を発行するための宣言。
-
profile: ユーザーの名前、プロフィール写真のURL、言語設定、誕生日（設定されていれば）など。
-
email: メールアドレスと、そのアドレスが確認済み（Verified）かどうか。
これらは、サービス側が「ユーザーアカウントを自動作成する」ために最低限必要な情報だね。
2. スコープ（Scope）による権限の切り分け
認証画面で「このアプリが以下の許可を求めています」って出るよね？あそこが運命の分かれ道。GoogleなどのIdPは、ユーザーが同意した範囲のデータにアクセスするための「鍵（アクセストークン）」 をサービス側に渡すんだ。
代表的な情報の種類
| カテゴリ | スコープの例 (Google) | 取得できる内容 |
|---|---|---|
| 連絡先 | contacts.readonly | 連絡先リスト、グループ情報 |
| カレンダー | calendar.events | 予定の閲覧、追加、編集 |
| ドライブ | drive.file | アプリが作成したファイルの操作 |
| YouTube | youtube.readonly | チャンネル登録状況、再生履歴 |
3. IDトークン（JWT）の中身を見てみよう
認証に成功すると、サービス側には JWT (JSON Web Token) という形式の「IDトークン」が送られてくるよ。君ならデコードしたことがあるかもしれないけど、中身はこんな感じのJSONデータなんだ。
JSON
{
"iss": "https://accounts.google.com",
"sub": "107630735144869306668", // ユーザーを一意に識別するID（不変）
"email": "[email protected]",
"name": "Asappy",
"picture": "https://lh3.googleusercontent.com/...",
"iat": 1516239022,
"exp": 1516242622
}
ここで重要なのは sub (Subject) だよ。メールアドレスは変更される可能性があるけど、このIDは一生変わらない。サービス側はこの値を主キー（Primary Key）にして、君のデジタルガーデンのユーザーデータと紐付けているんだね。
⚠️ 見落とされがちな落とし穴：過剰な権限要求
ときどき、単なるログインなのに「ドライブの全ファイルへのアクセス権」を求めてくるような行儀の悪いアプリがあるんだ。
-
リスク: もしそのサービスがハッキングされたら、君のGoogleドライブの中身まで丸見えになる。
-
対策: Googleなどのプロバイダは現在、「インクリメンタル認証」 を推奨しているよ。「最初はログインだけ、必要になった時に初めてカレンダーの権限を求める」という、最小権限の原則（Principle of Least Privilege）だね。
💡 豆知識：PII（個人識別情報）の保護
最近はプライバシー保護が厳しいから、Googleはデフォルトで渡す情報をどんどん減らしているんだ。
例えば、昔は「性別」なども簡単に取れたけど、今は明示的に許可が必要だったり、取得できなくなっていたりする。Appleの「Sign in with Apple」なんて、「自分のメールアドレスを隠して、ランダムな転送用アドレスをサービスに渡す」 という、さらに一歩進んだプライバシー保護機能を持っているよ。
結論
認証プロバイダが与える情報の範囲は、「ユーザーが同意したスコープの範囲内」 に厳格に閉じ込められている！
でも、一度渡してしまったアクセストークンが有効な間は、サービス側はバックグラウンドでそのデータ（カレンダー等）を読み取ることができるから、不必要になった連携はGoogleのアカウント設定からこまめに解除するのが、情報工学を学ぶ者の嗜みだね。
次は、この認証の仕組みを支える 「JWTの署名と検証（公開鍵暗号）」 の数学的な美しさについて話してみる？それとも、自分でIdPを作るときに役立つ 「Auth0やFirebase Authなどの認証プラットフォームの比較」 をやってみるかな！