OAuth 認可サーバー実装のセキュリティ

OAuth の /authorize では、GET リクエストで authorization code を即発行せず、ログイン状態と request validation を確認したうえで同意画面を返す。code 発行はユーザーが approve した POST のみで行い、consent 用の短寿命 token を cookie と hidden field の両方で照合すると、意図しない承認 POST や CSRF 的な操作を防ぎやすい。

authorization code や refresh token を一度だけ使わせる場合、読み取り後に別 update するだけでは並行リクエストで再利用される可能性がある。used_at IS NULL や revoked_at IS NULL、expires_at > now の条件を含む update を transaction 内で実行し、affected rows が 1 件のときだけ token pair を作成すると、再利用レースを防ぎやすい。

Dynamic Client Registration は未認証で client 登録を受けることが多いため、rate limit が必須になる。Gin などの framework で ClientIP() を使う場合、trusted proxies や X-Forwarded-For の扱い次第で spoof される可能性があるため、公開 endpoint の制限では RemoteAddr など接続元として信頼できる値を使うか、proxy 境界を明示的に設定する。

OAuth authorize 中に外部ログインを開始し、まだアプリ側ユーザー作成や初期設定が完了していない場合、ログイン callback だけで return URL を消費すると OAuth フローへ戻れなくなる。authorize への return URL は短寿命 cookie などで setup 完了まで保持し、完了後に安全性を検証してから /authorize に戻すと、初回ユーザーでも連携フローを継続できる。

OAuth consent 画面を外部クライアントの埋め込みブラウザや connector UI で表示する場合、通常のブラウザで通る CSP でも form-action が送信をブロックすることがある。form-action の allowlist を入れても同一の送信先が拒否される環境では、consent route に限って form-action directive を外し、script-src 'none'、object-src 'none'、base-uri 'none'、frame-ancestors 'none'、hidden token と cookie 照合など他の防御を残す選択肢がある。

OAuth authorize への return URL を cookie などに保存してログイン後に redirect する場合、保存処理が自前 middleware だけでも、使用直前に host、scheme、path を検証する。許可する path を /oauth/authorize などに限定し、host は空または現在の host、scheme は空または http/https のように絞ると、cookie 改ざんや将来のコード変更による open redirect を防ぎやすい。