OAuth 2.0とは？一言でいうと「合鍵を渡さずにサービスを連携する仕組み」
OAuth 2.0（オーオース 2.0）は、ユーザーのパスワードを第三者に渡すことなく、外部サービスにデータへのアクセス権限を委譲するための認可フレームワークです。2012年にRFC 6749として標準化されました。
たとえるなら、ホテルのカードキーに似ています。マスターキー（パスワード）を他人に渡す代わりに、「この部屋だけ」「チェックアウトまで」という制限付きのカードキーを発行する——OAuth 2.0はこのような限定的なアクセス許可を実現します。
身近な例としては、「Googleアカウントでログイン」「GitHubでサインイン」といったソーシャルログインの裏側でOAuth 2.0が動いています。
なぜOAuth 2.0が必要なのか？パスワード共有の危険性
OAuth 2.0が登場する以前、サービス連携にはユーザーのIDとパスワードを直接渡す方法が一般的でした。しかし、この方法には重大な問題があります。
| 問題点 | 具体的なリスク |
|---|---|
| パスワード漏洩 | 連携先がハッキングされると、元のサービスのパスワードも流出する |
| 権限の制御不可 | パスワードを渡すと全権限を与えることになり、「読み取りだけ」などの制限ができない |
| 取り消しが困難 | 連携を解除するにはパスワード変更が必要で、他の連携にも影響する |
OAuth 2.0はアクセストークンという一時的な「許可証」を使うことで、これらの問題をすべて解決しています。
OAuth 2.0の登場人物（4つのロール）
OAuth 2.0を理解するには、まず4つの登場人物を押さえましょう。
| ロール | 役割 | 具体例 |
|---|---|---|
| リソースオーナー | データの持ち主（＝ユーザー） | Googleアカウントを持つあなた |
| クライアント | データにアクセスしたいアプリ | Notionやslackなどの外部アプリ |
| 認可サーバー | アクセス許可を管理し、トークンを発行 | Googleの認可サーバー |
| リソースサーバー | 実際のデータを保持するサーバー | Google Drive API、Gmail API |
認可コードフロー：最も安全な標準フロー
OAuth 2.0にはいくつかのフロー（認可の手順）がありますが、Webアプリケーションで最も推奨されるのが認可コードフロー（Authorization Code Flow）です。
フローの流れ（5ステップ）
Step 1：ユーザーがクライアントアプリで「Googleでログイン」ボタンをクリック
Step 2：クライアントがGoogleの認可サーバーにリダイレクト。ユーザーは「このアプリにメール閲覧を許可しますか？」という画面で同意する
Step 3：認可サーバーがクライアントに認可コード（一時的なコード）を返す
Step 4：クライアントが認可コードを使って、バックエンドから認可サーバーにアクセストークンを要求
Step 5：アクセストークンを使って、リソースサーバー（Gmail APIなど）からデータを取得
ポイントは、アクセストークンがブラウザに直接露出しない点です。認可コードを中継することで、トークンの漏洩リスクを最小化しています。
その他の主要フロー
| フロー名 | 用途 | 特徴 |
|---|---|---|
| クライアントクレデンシャル | サーバー間通信（ユーザー不在） | マシン対マシンの認可に使用 |
| PKCE付き認可コード | モバイルアプリ・SPA | 認可コードフローをパブリッククライアント向けに強化 |
| デバイスコード | スマートTVやIoTデバイス | キーボード入力が困難なデバイス向け |
OAuth 2.0とOpenID Connectの違い
OAuth 2.0と混同されやすいのがOpenID Connect（OIDC）です。両者の違いを整理しましょう。
| 比較項目 | OAuth 2.0 | OpenID Connect |
|---|---|---|
| 目的 | 認可（このアプリにデータアクセスを許可） | 認証（このユーザーが本人であることを確認） |
| 発行するもの | アクセストークン | アクセストークン＋IDトークン |
| ユーザー情報 | 標準的な取得方法は未定義 | UserInfoエンドポイントで標準化 |
| 関係性 | 基盤の仕組み | OAuth 2.0の上に構築された拡張 |
簡単にいうと、OAuth 2.0は「何を許可するか」を扱い、OpenID Connectは「誰であるか」を扱う仕組みです。「Googleでログイン」の裏側では、OAuth 2.0 + OpenID Connectが組み合わされています。
スコープとトークン：アクセス制御の仕組み
スコープ（権限の範囲）
OAuth 2.0ではスコープを使って、アプリに与える権限を細かく制御します。たとえばGoogle APIでは以下のようなスコープがあります。
email：メールアドレスの読み取りprofile：基本プロフィール情報の読み取りhttps://www.googleapis.com/auth/drive.readonly：Google Driveの読み取り専用
ユーザーは同意画面で「このアプリに○○を許可します」という形で、どのスコープを許可するか選択できます。
トークンの種類
| トークン | 役割 | 有効期間 |
|---|---|---|
| アクセストークン | APIへのアクセスに使用 | 短い（数分〜数時間） |
| リフレッシュトークン | アクセストークンの再発行に使用 | 長い（数日〜数ヶ月） |
アクセストークンの有効期間を短く設定し、リフレッシュトークンで更新する設計により、万が一トークンが漏洩しても被害を最小限に抑えられます。
よくある質問（FAQ）
Q. OAuth 2.0は「認証」のプロトコルですか？
いいえ。OAuth 2.0は「認可」のフレームワークです。「誰であるか」を確認する認証機能は含まれていません。認証が必要な場合はOAuth 2.0の上に構築されたOpenID Connectを使います。
Q. OAuth 1.0とOAuth 2.0の違いは？
OAuth 1.0は署名ベースで実装が複雑でしたが、OAuth 2.0はHTTPS前提でシンプルになりました。また、OAuth 2.0ではモバイルアプリやSPAなど多様なクライアント種別に対応するフローが追加されています。現在、新規開発ではOAuth 2.0が標準です。
Q. 開発者としてOAuth 2.0を実装するには？
自前で実装するのはセキュリティリスクが高いため、Auth0、Firebase Authentication、AWS Cognitoなどのマネージドサービスの利用が推奨されます。どうしても自前実装が必要な場合は、OAuthライブラリ（Spring Security、Passport.jsなど）を活用しましょう。
まとめ：OAuth 2.0はモダンWeb開発の必須知識
OAuth 2.0は、パスワードを共有せずにサービス間のデータ連携を安全に実現する認可フレームワークです。ソーシャルログインやAPI連携など、現代のWebサービスのほとんどがOAuth 2.0に依存しています。認可コードフロー、スコープ、トークンの概念を理解することで、セキュアなアプリケーション設計ができるようになります。
コメント