OAuth が解決する問題
OAuth が生まれる前、サードパーティアプリにデータを共有するには パスワードを渡すしかありませんでした。この章では、なぜそれが危険で、 OAuth がどのように解決したのかを学びます。
パスワード共有の時代
2007年以前、あるサービスが別のサービスのデータにアクセスしたい場合、 ユーザーは自分のパスワードを直接渡す必要がありました。 例えば、写真印刷サービスが Google Photos の写真にアクセスするには、Google のパスワードをそのサービスに教えなければなりませんでした。
パスワードを渡すと、写真の閲覧だけでなく、 メールの送信、連絡先の削除、アカウント設定の変更まで すべてが可能になってしまいます。
一度パスワードを教えてしまうと、パスワード自体を変更しない限り アクセスを取り消せません。変更すると、他の正当なサービスにも 影響が出ます。
パスワードを知るサービスが増えるほど、漏洩のリスクが高まります。 一つのサービスが攻撃を受ければ、あなたのアカウントが危険にさらされます。
鍵の例えで理解する
パスワード共有の問題を、マンションの鍵に例えて考えてみましょう。
# パスワード共有 = マスターキーを渡す
清掃業者に依頼したい
→ マスターキーのコピーを渡す
結果:
- 全部屋に入れる
- 金庫も開けられる
- いつでも出入り自由
- 取り消すには鍵交換が必要
# OAuth = 制限付き合鍵を作る
清掃業者に依頼したい
→ リビングだけの合鍵を作る
結果:
- リビングのみアクセス可
- 金庫は開けられない
- 期限付き（有効期限あり）
- いつでも無効化できる
OAuth による解決
OAuth は「パスワードを渡す代わりに、制限付きのトークン（合鍵）を 発行する」という仕組みです。これにより、以下が実現されました。
「写真の読み取りのみ」「プロフィール情報のみ」のように、 必要最小限の権限だけを許可できます。
パスワードを変更せずに、特定のアプリのアクセスだけを 取り消すことができます。
サードパーティアプリはパスワードを知ることなく、 必要なデータにアクセスできます。
トークンには有効期限があり、期限が切れると自動的に アクセスできなくなります。
OAuth の基本的な流れ
# 写真印刷アプリが Google Photos にアクセスする場合
[ユーザー] → 写真印刷アプリを使いたい
[印刷アプリ] → 「Google Photos へのアクセス許可をください」
[ユーザー] → Google のログイン画面で認証
[Google] → 「写真の読み取りを許可しますか？」
[ユーザー] → 「許可する」
[Google] → 印刷アプリにアクセストークンを発行
[印刷アプリ] → トークンを使って写真を取得
# ポイント: ユーザーのパスワードは印刷アプリに渡らない
次のステップ
認証 vs 認可