MIRACL Trust Authenticator

The MIRACL Trust Authenticator is a mobile application available for the two major platforms - iOS and Android . It lets you use the MIRACL Trust authentication technology with minimal integration, allowing you to authenticate to a web application, regardless of where it is accessed from.

To use Custom User Verification with the MIRACL Trust Authenticator, you must first set up a Custom Verification URL in the MIRACL Trust Portal. When the end user starts registering in the MIRACL Trust Authenticator, they are redirected to the Custom Verification URL. To register the user, the MIRACL Trust Authenticator must consume the Verification URL obtained by the verification request.

Note: Custom Verification URL is different from Verification URL.

  • Custom Verification URL is the registration URL in your system that you set up in the MIRACL Trust Portal.
  • Verification URL is the platform-issued URL that is used to transfer the verification to the platform, finishing the verification flow.

The Verification URL is generated by making an authenticated POST request to <https://<PROJECT_DOMAIN>/verification>.

curl \
    --request POST \
    --user "${CLIENT_ID}:${LIENT_SECRET}" \
    --data '{
        "projectId": "'"${PROJECT_ID}"'",
        "userId": "'"${USER_ID}"'",
        "deviceName": "'"${DEVICE_NAME}"'",
        "expiration": "'"${EXPIRATION}"'",
        "delivery": "no"
    }' \
    https://${PROJECT_DOMAIN}/verification

With the following response:

{
  "verificationURL": "https://<PROJECT_DOMAIN>/verification/confirmation?user_id=<USER_ID>&code=<CODE>"
}

All values are redacted.

See MIRACL Trust Backend API for more details.

You can redirect the end user to the Verification URL which will be handled by the MIRACL Trust Authenticator.

Another option is to send the Verification URL to the end user via any appropriate secure channel (email, SMS, etc.), and when they open it, the verification is completed.

If the registration is successful, the enrolment process is completed. End users can now authenticate using the PIN chosen for the device. They can go through the verification process for each device they want to use for authentication or use QuickCode , if enabled, to enrol additional devices using the already enrolled one.

# Flow

sequenceDiagram actor User as User Agent participant App as MIRACL Trust Authenticator participant RPA as Relying Party Application participant MIRACL as MIRACL Trust User ->> RPA: Request verification RPA ->> MIRACL: Redirect to MIRACL Trust OIDC Authorization Page MIRACL -->> User: User ->>+ MIRACL: Wait for verification par App ->>+ MIRACL: Scan QR code MIRACL -->> App: App -->> RPA: Open Custom Verification URL in web view RPA ->> RPA: Verify user RPA -->> App: Redirect to Verification Confirmation URL App ->> MIRACL: MPin Protocol MIRACL -->>- App: end MIRACL -->>- User: Enrol device

Relying Party Application is your application’s back end.

When a client requests access to a protected resource, the Relying Party Application redirects the end user to the MIRACL Trust Authorisation Page to begin authentication via OpenID Connect.

To verify their identity and register their device, the user must use the MIRACL Trust Authenticator. On desktop, this involves scanning a QR code displayed in the browser using the mobile app. On mobile, the user simply taps the Launch App button to open the MIRACL Trust Authenticator directly.

After launching the app, the end user is redirected to a Custom Verification URL, where the Relying Party Application handles identity verification. Via the Verification URL, the end user is redirected back to the MIRACL Trust Authenticator, and the verification is complete. Now, the end user can authenticate using the PIN associated with their registered device.

Once authentication is successful, the end user is directed to your OIDC Redirect URL along with the Access Code. The Relying Party Application then exchanges this Access Code for ID and Access tokens, confirming that the authentication was successful. This process may lead to creating a session on the back end, thereby granting the end user access to the protected resource.