When AllowIDPInitiated is true, the InResponseTo validation is not performed -- even for SP-initiated flows that have an InResponseTo value. This means enabling IdP-initiated SSO also disables request binding validation for SP-initiated flows, allowing assertion replay attacks.
The fix: only skip validation when InResponseTo is empty AND AllowIDPInitiated is true (i.e., a genuine unsolicited response). When InResponseTo is present and non-empty, validate it against tracked request IDs regardless of the flag.
Some IdPs (notably Rippling) set InResponseTo to arbitrary values on IdP-initiated flows. The existing ValidateRequestID hook handles that case.
Fix: fix/issue-03
When
AllowIDPInitiatedis true, theInResponseTovalidation is not performed -- even for SP-initiated flows that have anInResponseTovalue. This means enabling IdP-initiated SSO also disables request binding validation for SP-initiated flows, allowing assertion replay attacks.The fix: only skip validation when
InResponseTois empty ANDAllowIDPInitiatedis true (i.e., a genuine unsolicited response). WhenInResponseTois present and non-empty, validate it against tracked request IDs regardless of the flag.Some IdPs (notably Rippling) set
InResponseToto arbitrary values on IdP-initiated flows. The existingValidateRequestIDhook handles that case.Fix:
fix/issue-03