Skip to main content

Sign transactions with push notification

Transaction signing is an operation that is initiated within an already authenticated session. This operation is very similar to authentication, but transaction signing can also be initiated by a privileged user (such as a helpdesk user), not only by the end user.

info

The Nevis Mobile Authentication SDK allows the use of the fetch channel to get a list of ongoing operations for a specific device. This ensures that if there is intermittent or network lag, or if the push service is unavailable, users can always be provided with the request they generated. For more information, see the relevant sections in the documentation for Nevis Mobile Authentication SDK and nevisFIDO.

The following diagram shows the end-to-end sequence of signing a transaction with push notification. The steps that must be performed to integrate the Authentication Cloud into your application are in bold.

Send an HTTP request to the approval endpoint

For detailed information on the HTTP request parameters and response fields, see the Approval endpoint page of the API reference documentation.

Send the POST https://{instance}.mauth.nevis.cloud/api/v1/approval call with your instance ID, and configure the HTTP request as follows:

  1. Send your access key or intent token in the Authorization Bearer token header. For more information on the intent token, see Intent endpoint.
  2. Set the channel parameter to push.
  3. Set the username or userId parameter.
  4. Set the prompt parameter to true. This creates a flag to request the user to actively accept or deny the authentication.
  5. Configure the message parameter. This displays a notification message on the user device.

    You can format the message with a limited set of supported HTML tags. To enable text formatting, enclose the transaction confirmation text in the <html></html> HTML tags. If you include an unsupported tag, such as <p> or <div>, or add any attribute to a tag, you will receive an HTTP 400 Bad Request response. The following tags and formatting options are supported:

    • <b></b>: bold
    • <br>: line break
    • <em></em>: emphasis
    • <i></i>: italic
    • <strong></strong>: strong
    • <u></u>: underline
  6. Optionally, configure the notificationMessage parameter to display a notification message in the notification center or notification drawer.
  7. To authenticate the transaction with a specific authenticator, set the authenticatorId parameter. If this parameter is not configured, the default authenticator is used, which is the authenticator registered most recently.

HTTP request examples

cURL code sample for transaction singing using push
curl "https://$instance.mauth.nevis.cloud/api/v1/approval" \
-XPOST \
-H "Authorization: Bearer $access_key" \
-H 'Content-Type: application/json' \
-d "{ \"channel\": \"push\",
\"username\": \"$username\",
\"prompt\": true,
\"message\": \"$message\",
\"notificationMessage\": \"$notification_message\" }"

Once the authentication operation is started, Authentication Cloud transmits the push to Google Firebase, which then sends the push notification to the mobile app. If the user is rate limited, the authentication operation fails. Authentication Cloud then sends a response to your application with a transactionId and a statusToken.

Then, the push notification is displayed on the user device.

If the push rate limiting feature is enabled, Authentication Cloud checks whether the user is rate limited for push before transmitting the push to Google Firebase. If yes, the authentication operation fails and a HTTP 429 - Too many requests error is returned. In a successful approval operation, the rateLimitInfo.push.sent field in the HTTP response contains the number of push notifications sent in the previous 24 hours.

HTTP response example

201 Created: Approval using push

{
"transactionId": "e7c4328a-5497-4768-ac49-471db85defd4",
"userId": "7e16ba00-92e2-4fcb-b30e-1af8fdc843aa",
"statusToken": "eyJhb...CGJNfkA"
}

Start polling the status endpoint

To verify the success of the approval operation, start polling the status endpoint from your frontend application. The recommended polling interval is 1.5 seconds. Depending on your circumstances, such as user needs and production system capabilities, you might need to adjust the wait times between two polling cycles.

For detailed information on the HTTP request parameters and response fields, see the Status endpoint page of the API reference documentation.

Send the POST https://{instance}.mauth.nevis.cloud/api/v1/status call with your instance ID, and configure the HTTP request as follows:

  1. Send the statusToken that was retrieved during the approval operation.

  2. Poll for the status as long as status is pending.

When you receive a succeeded, failed, or unknown status, you can react accordingly. If the status is succeeded, continue with verifying the operation from your backend application.

After accepting the push notification, the user can authenticate themselves, for example, with PIN or biometric data. The authentication response to the Authentication Cloud includes a signed message. The response is validated with the previously stored public key.

HTTP request examples

Code sample for status polling
# Set $statusToken
curl "https://$instance.mauth.nevis.cloud/api/v1/status" \
-XPOST \
-H 'Content-Type: application/json' \
-d "{ \"statusToken\": \"$statusToken\" }"

HTTP response examples

200 OK: Pending - The operation is still waiting for confirmation by the user

{
"transactionId": "b7d44592-91f3-4f4b-9e37-202a3061edc3",
"status": "pending",
"userId": "7e16ba00-92e2-4fcb-b30e-1af8fdc843aa",
"username": "Userxyz123",
"token": "eyJhb...Fl9bpEXGGw",
"createdAt": "2020-10-09T12:52:48Z",
"lastUpdatedAt": "2020-10-09T12:52:48Z"
}

After confirming the push notification, the user can authenticate themselves, for example, with PIN or biometric data. The authentication response to the Authentication Cloud includes a signed message. The response is validated with the previously stored public key.

Verify the operation

Once the authentication is successful and you receive the server response, verify the operation. Use of the following verification methods:

  • HTTP request to the status endpoint
  • HTTP request to the introspect endpoint

Send an HTTP request to the status endpoint

By calling the status endpoint from your backend application, you request Authentication Cloud to verify the validity and the authenticity of the operation. This is done by using the statusToken from the previous HTTP response.

For detailed information on the HTTP request parameters and response fields, see the Status endpoint page of the API reference documentation.

Send the POST https://{instance}.mauth.nevis.cloud/api/v1/status call with your instance ID and include the statusToken that was retrieved during the operation.

Send an HTTP request to the introspect endpoint

By calling the introspect endpoint from your backend application, you request Authentication Cloud to verify the validity and the authenticity of the user. This is done by using the transaction token returned by the status endpoint.

For detailed information on the HTTP request parameters and response fields, see the Introspect endpoint page of the API reference documentation.

Send the POST https://{instance}.mauth.nevis.cloud/api/v1/introspect call with your instance ID, and configure the HTTP request to the introspect endpoint as follows:

  1. Send your access key in the Authorization Bearer token header.
  2. Add your token that you want to verify.

HTTP request examples

cURL code sample for checking the validity and authenticity of a token
# Set $token
curl "https://$instance.mauth.nevis.cloud/api/v1/introspect" \
-XPOST \
-H "Authorization: Bearer $access_key" \
--data-urlencode "token=$token"

HTTP response examples

200 OK: Active and valid access key

{
"active": true,
"iat": 1642436165000,
"sub": "c8edb1d1-6dac-470f-b2fb-c25277a5c5b6",
"aud": "api",
"iss": "https://{instance}.mauth.nevis.cloud/"
}