OAuthの基本と認証・認可の違い
OAuthは「認可」のフレームワークです。つまり、リソースへのアクセス権限を委譲する仕組みです。しかし、「認証」とは異なります。なぜなら、「誰であるか」を確認する仕組みではないからです。
たとえば、GoogleログインはOAuthで権限を委譲しています。しかし「この人が本人か」の認証はOpenID Connectが担います。つまり、この2つを混同すると設計に穴が生まれます。実際、この混同が多くのセキュリティ事故を引き起こしています。
OAuthの主要な脆弱性と対策
OAuth実装でよくある脆弱性があります。まずリダイレクトURI検証の欠陥です。パターンマッチエラーによりトークンが盗まれるケースです。また、認可コードインジェクション攻撃もあります。
そこでPKCE(Proof Key for Code Exchange)が重要になります。RFC 9700ではサーバー側でのPKCE対応が必須化されました。具体的には、クライアントがcode_verifierを生成し、ハッシュ化して送信します。さらにインプリシットグラントは非推奨です。つまり、最新のベストプラクティスに従うことが不可欠です。
OAuthのトークン管理のベストプラクティス
トークン管理も重要なポイントです。まず短命なアクセストークンを使用しましょう。なぜなら、盗難時の被害期間を制限できるからです。また、不要になったトークンはすぐに失効させます。
さらに保存時は必ず暗号化してください。具体的には、AndroidではKeystore、iOSではKeychainを活用します。加えて、スコープを最小限に絞ることも大切です。つまり、必要な権限だけを要求する「段階的認可」を実践しましょう。
OAuth設計で避けるべきアンチパターン
避けるべきパターンもあります。まずリソースオーナーパスワードグラントはRFC 9700で禁止されました。また、シークレットをコードにハードコードするのも厳禁です。さらに組み込みWebビューの使用も避けてください。そのため、フル機能ブラウザを使うべきです。
まとめ
OAuthは認可のフレームワークであり認証との区別が重要です。特にPKCEの必須化やトークン管理がポイントです。したがって、最新のRFC 9700に準拠した設計を心がけてください。