Diagram: Associate check → Retrieve result → Execute action → Confirm outcome
Original illustration for Access Signal. Guide and sources checked October 23, 2026.

Explore checkers, demos and evaluation routes →

Summarize this page with

A login-risk integration must connect the account action to a trusted result and a completed response. Collect the required client evidence, associate it with the intended operation, retrieve the result through the documented server path and confirm what the identity provider or application actually did. Missing evidence is a separate state from a low-risk result.

  1. 1Associate check
  2. 2Retrieve result
  3. 3Execute action
  4. 4Confirm outcome
A practical sequence for the question covered in this guide.

Where should the check run?

Choose the protected operation before installing code: issuing the application session, changing recovery information, adding a factor or authorizing a sensitive action. Different products support different checkpoints and timing. A result that arrives after access is issued may support investigation or containment rather than the original login decision.

Follow the vendor’s current integration contract. Castle documents client request tokens and server-side login activity. DataDome documents a distinct Account Protect SDK and API key. ShieldLabs provides collection, account association and trusted result delivery through its documented interfaces.

Which references should be bound together?

Keep an application-generated action reference, a protected account reference, the vendor check reference and timestamps. Validate that the retrieved result belongs to the expected site, action and time window where the vendor supports those checks. Do not accept an arbitrary client-supplied score as the server’s source of truth.

Use the exact documented response fields and authentication method. The following is an illustrative application state model, not a vendor API contract:

action_id + account_reference
    -> evidence collected or missing
    -> trusted result received or timed out
    -> allow / fresh verification / deny / investigate
    -> authentication and application outcome recorded

The application’s audit record should preserve each transition. This makes a late result distinguishable from a result that was available before the action.

How should the result reach the IdP?

Use the supported extension point for the actual identity product. Workforce Okta, Auth0 application flows and Entra Conditional Access are not interchangeable interfaces. An event API or webhook from a risk product does not automatically establish a ready-made connector for every provider.

Confirm how the integration requests fresh verification, what factor is appropriate and how success or failure returns to the original action. Do not label a challenge as completed merely because a request to start it succeeded. For a sensitive change, preserve the action until the intended proof is established.

What happens on a timeout or missing check?

Comparison of the methods and conditions discussed in this section.
State Required integration decision
No client evidence Use an explicit fallback appropriate to the protected action
API unavailable Apply the documented timeout path; record degraded coverage
Late result Determine whether access can still be limited or investigated
Reused reference Reject or handle according to the vendor’s replay contract
Step-up failed Keep the protected action from silently completing
Partial revocation Track the sessions or tokens still requiring action

There is no universal fail-open or fail-closed choice for every operation. A low-consequence read and changing the recovery email have different requirements. Make the decision explicit and test it rather than relying on an exception handler that grants access unintentionally.

What should a webhook receiver verify?

Follow the provider’s documented verification method, event identifier and retry behavior. Retrieve additional details through the trusted API when needed. Make processing idempotent and separate receiving the event from applying a potentially disruptive account action.

Avoid placing API keys or sensitive response bodies in browser code or analytics. A public collection key and a privileged server credential serve different purposes. Test duplicate delivery, out-of-order events and a retry after the account has already completed recovery.

How do you confirm end-to-end behavior?

Use permitted test accounts to trace one login, one genuine new-device verification, one sensitive account change and one containment action. Compare timestamps across the collection, risk, identity and application systems. Confirm that the protected operation can no longer be performed after revocation where intended.

Only then assess detection and owner friction on a representative labelled set. The evaluation worksheet supplies the denominators, while the recovery guide addresses the path that restores access.

FAQ

Can the browser send the final risk score directly to the backend?

Treat browser-supplied values as untrusted. Use the vendor’s documented server-side retrieval or verified delivery path and associate the result with the intended check and account action.

Does receiving a webhook mean the account was protected?

No. Verify the event, process it safely and confirm the actual access or session action in the identity and application systems. Receipt and completed enforcement are different observations.

Is there one integration recipe for Okta, Auth0 and Entra?

No. They have distinct products, entitlements and extension points. Check the actual identity flow and supported vendor interface instead of assuming a generic API result creates a native connector.

Sources

Primary sources checked October 23, 2026.

Continue reading

Compare all ten tools or read the complete deployment guide.