Overview

A core component of most user journeys through Trinsic is the final redirect back to your application or website.

If you use Hosted Provider Sessions, every Session is redirect-based; if using Direct Provider Sessions, any session with a CaptureRedirect result-collection method is redirect-based.

Handling these redirects correctly and securely is critical for any integration with Trinsic.

Guide

There are three general scenarios in which a user will be redirected back to your application:

1) On Success

In cases where a Session has completed successfully, the user is redirected back with the Successful Parameters documented below.

You will always receive a redirectToken and a sessionId.

2) On Session Failure

If a user's journey ends with a Session-ending failure (e.g., a user refusing consent; a digital signature failing to validate; a Provider being unreachable; etc.) then the user is redirected back with the Failure Parameters documented below.

The redirectReason for this scenario will always be VerificationFailed.

3) On Non-Session-Ending Failure

WOT I WANT TO SAY GUV:

• Intro: Handling user redirects is a critical part of any Trinsic integration
  • Every Hosted session requires it
  • Direct requires it for most Providers
• Handling Redirects
  • redirectToken
  • User Identification
• Threat Model
  • Redirects can introduce phishing vectors (Session Fixation)
  • We need to know two things:
    • A) the user being redirected back from Trinsic is the same one who initially visited Trinsic
    • B) the user who initially visited Trinsic is the same one who was authenticated with the customer originally