OAuth 2.0 - Autorización delegada seguraとは

Lectura de 2 min aprox.

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 など) 自体のセキュリティも極めて重要です。 メインアカウントが乗っ取られると、連携する全サービスに影響が及びます。 パスつく.com で生成した強力なパスワードと二段階認証で メインアカウントを保護しましょう。Web アプリケーションセキュリティの書籍 (Amazon)も参考になります。