OAuthとは

この記事は約 2 分で読めます

OAuth とは、ユーザーのパスワードを第三者に渡すことなく、アクセス権限を安全に委譲するための認可プロトコルです。「 Google でログイン」「 Twitter でログイン」といったソーシャルログイン機能の基盤技術として広く利用されています。OAuth 2.0 は Web アプリケーションやモバイルアプリ向けのフローを定義した仕様です。 2025 年時点では OAuth 2.1 の策定が進んでおり、 PKCE の必須化やインプリシットフローの廃止など、セキュリティの強化が図られています。

OAuth と SSO の違い

OAuth と SSO は混同されやすい概念ですが、目的が異なります。 OAuth は「認可」のプロトコルであり、「このアプリに写真へのアクセスを許可する」といった権限の委譲を扱います。一方、 SSO は「認証」の仕組みであり、「一度のログインで複数のサービスにアクセスする」ことを目的とします。実際には OAuth の上に OpenID Connect (OIDC) という認証レイヤーを追加することで、 OAuth を SSO の基盤として利用するケースが一般的です。つまり、 OAuth は SSO を実現するための技術的な部品の 1 つと捉えることができます。

OAuth の仕組み

OAuth では、ユーザーが認可サーバーで認証を行い、アクセストークンが発行されます。アプリケーションはこのトークンを使って API にアクセスし、ユーザーのパスワードを直接扱うことはありません。トークンにはスコープ (権限範囲) と有効期限が設定され、必要最小限のアクセス権のみが付与されます。リフレッシュトークンを使えば、ユーザーの再認証なしにアクセストークンを更新できます。

トークンが漏れてもパスワードほど致命的でない理由

OAuth の設計を理解する鍵は、漏洩したときの被害の違いにあります。パスワードが漏れると、攻撃者は本人と同じ全権限を、持ち主が変更するまで無期限に行使できます。これに対しアクセストークンは、権限がスコープで絞られ、有効期限が切れれば自動的に無効になるため、漏れた場合でも使える範囲と時間の両方に上限があります。さらに認可サーバー側で連携を取り消せば、パスワードを変更することなくそのアプリへの権限だけを失効させられます。アプリにパスワードそのものを渡す方式では、この「部分的に渡し、部分的に取り消す」ことができません。有効期限の短いトークンとリフレッシュトークンの組み合わせは、利便性を保ったまま漏洩時の被害を構造的に限定するための仕組みです。

OAuth 認可フロー

実務での注意点と落とし穴

OAuth を利用する際は、アプリケーションに付与する権限を最小限に留めることが重要です。「連絡先へのアクセス」「メールの読み取り」など不要な権限を要求するアプリには注意が必要です。実務でよくある落とし穴は、 OAuth 連携を設定した後に放置してしまうことです。使わなくなったアプリの連携は定期的に見直し、不要な権限を取り消しましょう。また、 OAuth で連携するメインアカウント (Google 、 Apple など) 自体のセキュリティも極めて重要です。メインアカウントが乗っ取られると、連携する全サービスに影響が及びます。サービスごとに固有の強力なパスワードと二段階認証でメインアカウントを保護しましょう。