ひとことで言うと
OAuthは、あるサービスが別のサービスに「この範囲だけ操作してよい」という許可を、パスワードを渡さずに安全に伝えるための仕組みです。
「Googleでログイン」「GitHubでログイン」というボタンを見たことがあるはずです。 あれはパスワードをそのアプリに渡しているわけではなく、GoogleやGitHubが「このアプリに、この情報へのアクセスを許可する」という証明を発行する流れを使っています。これがOAuthです。
たとえ話でもう少し詳しく
OAuthは、ホテルのカードキーの発行に近いです。
- お客さんはフロントに本物の鍵（パスワード）を渡さない
- 代わりに「201号室だけ開けられるカード」を作ってもらい、それをスタッフに渡す
- スタッフはそのカードで部屋に入れるが、他の部屋には入れない
- カードは期限つきで、用が済めば返却・無効化できる
Webサービスでも同じです。 「このアプリにGoogleカレンダーの読み取りだけ許可する」と承認すると、アプリはGoogleのパスワードを知らなくても、許可された範囲だけGoogleカレンダーにアクセスできます。 許可を取り消せば、アプリはアクセスできなくなります。
OAuthの大まかな流れ
- アプリが「Googleでログイン」ボタンを表示する
- ユーザーがGoogleの画面でログインし「このアプリに○○を許可する」と承認する
- Googleがアプリに「許可証（アクセストークン）」を渡す
- アプリはそのトークンを使って、許可された範囲のGoogleサービスにアクセスする
ユーザーのパスワードはGoogleの外には一切出ません。
よく出る場面・使いどころ
- 「Googleでログイン」「GitHubでログイン」などのソーシャルログイン
- 会計ソフトが銀行サービスのデータを自動取得するとき
- スケジュールアプリが別サービスのカレンダーと同期するとき
- CI/CDツールがGitリポジトリを操作するとき
似た言葉との違い
- 認証
- 「あなたは誰ですか」を確認すること
- OAuthは「あなたに代わってこのサービスがこの操作をしてよいですか」という許可の仕組み
- トークン
- 認証済みの証明として使う小さなデータ
- OAuthではアクセストークンという形でトークンが発行され、許可の証拠として使われる
- OpenID Connect
- OAuthの上に「誰が認証したか」という情報を乗せた拡張仕様
- 「Googleでログイン」の実装には多くの場合OAuthとOpenID Connectが組み合わされている
実務で気にするポイント
- 許可するスコープ（範囲）は必要最小限にする
- アクセストークンには有効期限を設け、不要になったら取り消す
- ユーザーが許可を取り消せる画面を用意する
- OAuthはあくまで「許可の仕組み」であり、それ単体では認証の完全な代替にはならない
注意: OAuthを「Googleでログインするだけの技術」と思っていると、設計の落とし穴にはまることがあります。OAuthは「誰かに代わって操作する許可を与える」仕組みです。実装する場合は、スコープの設計・トークン管理・フィッシング対策など、セキュリティの考慮が必要です。