When a SAML login fails at /login/callback because Auth0 cannot locate or validate the login transaction, the tenant log records a type: f event with oauthError: invalid_request and only the generic user-facing message (“You may have pressed the back button, refreshed during login, opened too many login dialogs, or there is some issue with cookies, since we couldn’t find your session…”).
This single message covers at least five distinct root causes: an expired login transaction, a missing or blocked transaction cookie (for example browser third-party cookie policies on the cross-site POST), an unsolicited IdP-initiated assertion sent to an SP-initiated connection, a replayed or already-consumed state, and assertion validation problems. Auth0 Support confirmed to us (support case [#____]) that none of the distinguishing details are available in any customer-accessible location, and that even Support needs a HAR file from the affected end user to determine the cause.
Describe the ideal solution
Keep the user-facing message generic as it is today, but enrich the tenant log event (visible only to tenant admins and log streams) with the request-level facts the ACS endpoint already evaluates:
- a reason code, for example transaction_not_found, transaction_expired, missing_transaction_cookie, unsolicited_idp_initiated_response, state_replayed
- whether a login-transaction cookie accompanied the callback (boolean)
- whether the SAMLResponse contained an InResponseTo value (boolean)
Alternatives and current workarounds
The only workaround today is capturing a HAR file from an affected end user and opening a support case. During a live outage at an enterprise customer, getting a HAR from a locked-out employee at a partner organization is slow and often not feasible.