【要約】【セキュリティ入門】第2回 OAuth 2.0とは？認可の仕組みを図解で理解する [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
外部アプリにサービス連携を許可する際、従来のパスワード共有方式では重大なセキュリティリスクがあった。ユーザーが外部アプリに自身のIDとパスワードを直接渡す必要があり、以下の問題が発生していた。
- ・権限範囲の制御不能：特定のデータのみのアクセス許可ができない。
- ・有効期限の設定不可：パスワードを変更するまで権限が永続する。
- ・個別取り消しの困難さ：連携解除のためにパスワード変更が必要となる。
- ・漏洩時の被害甚大：連携先でパスワードが漏洩すると本体アカウントが乗っ取られる。
// Approach
OAuth 2.0は、パスワードを直接渡すリスクを回避するため、アクセストークンを用いた権限委譲の仕組みを採用した。認可コード（引換券）を介した二段階のフローを用いることで、安全な権限譲渡を実現している。
- ・Authorization Code Grant：認可コードをフロントチャネルで受け取り、バックチャネルでトークンと交換する。
- ・PKCE：Public Clientにおいて、認可コードの横取りを防ぐための合言葉を用いる。
- ・state：ランダムな文字列を用いて、CSRF攻撃によるなりすましを防ぐ。
- ・redirect_uriの完全一致検証：認可コードが攻撃者のサイトへ送られるのを防ぐ。
// Result
本記事は、OAuth 2.0の複雑なフローとセキュリティ要件を、実務的な観点から整理している。開発者は、単なる実装手順だけでなく、防御の理由を理解できる。
- ・セキュリティリスクの低減：フロントチャネルとバックチャネルの分離により、トークン漏洩を防ぐ。
- ・最新仕様への準拠：RFC 9700に基づいたPKCEやstateの重要性を理解できる。
- ・設計ミスの防止：OAuth（認可）とOIDC（認証）の境界を明確にし、誤った設計を回避できる。
Senior Engineer Insight
> OAuthの実装において、最も致命的なのは「仕様の誤解」による脆弱性である。特に、redirect_uriのワイルドカード許可や、stateの不適切な実装は、認可コードの横取りやCSRFを招く。また、SPA等のPublic ClientではPKCEが事実上の標準である。現場では、ライブラリの初期設定を過信せず、issやaudの検証が正しく行われているかを厳格にレビューすべきである。