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 と Web セキュリティの書籍 (Amazon)で詳しく学べます。

現場での使用例

「新しい社内ツールの認証基盤に OAuth 2.0 + PKCE を採用しました。アクセストークンの有効期限を 15 分に設定し、リフレッシュトークンで自動更新する設計です。」

OAuth 認可フロー

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

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