ALBのOIDCフロールールセットでPOSTリクエストのデータが空になる

ALBのルールセットでOIDCフローを組んでいるWebアプリで起こったはなし。

UAのフォームPOSTデータが稀に空っぽでバックエンドに到達することがある。
クライアント環境/Webサーバー/アプリケーション/セッション層=自分の保守範囲で考えうる仮説と検証を繰り返してもどうしても穴がないため、フロント=>バックエンド間＝aws/idp層の調査を開始する。

ALB

問題発生時間帯のALBのアクセスログをAthenaでトレースするとめちゃめちゃど真ん中2に気になるアクセスログ/oauth2/idpresponse?code=...があった。
/oauth2/idpresponseといえば、ALBがOIDCフローのIDプロバイダからユーザの認証結果を受け取るリダイレクトのコールバックエンドポイントだ。

紐解くと、

• 1では、本来のPOSTのリクエストはバックエンド前段でALB層でUAがIDプロバイダに302リダイレクトされていることがわかる。
• 2では、IDプロバイダでユーザ検証が完了してALBにリダイレクトしてきたので、ALBが本来リクエストに302リダイレクト復帰させようとしている。
• 問題は3で、UAから本来POSTメソッドのリクエストがGETメソッドでリクエストされたので、バックエンドが送信元画面に302リダイレクトで差し戻している。
• 結果、4で、UAが差し戻しで元画面にリクエストしている。ユーザは2と、3が見えずこの間1秒未満なので、何かわからんが元画面に戻った？という状況

なお、1から2の間は、IDプロバイダの認証有効期限とか、ましてALBがUAに食わせる認証結果の収納クッキーの有効期限切れとか起こっているわけでもなく、定期的にIDプロバイダに送ってユーザ検証をしてくれていて、ログ全体でこの検証フローがたびたび発生していて、POSTリクエストに当たったときに問題として顕在化したようだ。

Httpメソッドとデータも維持して復帰してくださいよ、、と思うが、aws公式で、自分で対策してくれとレポートが出ているためしょうがない。

注: Application Load Balancer は 301 と 302 のリダイレクトのみをサポートします。これらのリダイレクトにより、クライアントは後続のリクエストで HTTP メソッドを POST から GET に変更できます。307 リダイレクトが必要な場合は、リダイレクトはターゲットアプリケーションを経由する必要があります。

Application Load Balancer を使用して、ドメインを別のドメインにリダイレクトする

対策

私のユースケースではOIDCフローは追加認証要素でありアプリ層には別途、認証と、一般的な検証＆ログインリダイレクト機構を担保しているので、
ホスト全体に適応していたALBのOIDCルールを認証ロケーションに狭めることで、IDプロバイダへの検証割り込みを回避することで対策とした。