auditing-idp-initiated-flow-trustlisted

# Auditing IdP-initiated flow trust: an unsolicited login has no request to anchor it, so validate everything else In service-provider-initiated single sign-on the application starts the flow, so it has a request on file to bind the returning assertion to: a request id it can require the response to reference, and request state it can check. IdP-initiated single sign-on removes that anchor. Login begins at the identity provider and the application receives an assertion it never asked for, with no matching request, no InResponseTo to check, and no request state to compare against. Everything the request would have pinned down, that this response answers a login this browser started, must now be validated some other way, and often is not. An unsolicited assertion an attacker captures can be replayed, or delivered to a victim, to log a browser into an attacker-chosen account. A RelayState value trusted as a redirect target becomes an open redirect or drops the user into an attacker-controlled context after login. An assertion with no audience restriction, or one too wide, is accepted by a service provider it was never meant for. And without a replay defense, one-time-use, a tight expiry, a consumed-assertion cache, the same assertion logs in again and again. The audit treats an unsolicited assertion as untrusted, checks its signature, audience, timing, and single-use, and refuses to trust RelayState as a destination. You audit this by capturing an IdP-initiated assertion and tr