Handling verify request on enterprise backend

Technologies used for the demonstration of enterprise backend client implementation: Kotlin, Spring Boot.

In order to successfully use the Silent Mobile Verification, the backend service should be able to:

1. Resolve device IP address
2. Send the verify request to Infobip and handle the callback
3. Provide a polling endpoint to the end-user client

Resolve device IP address

Defining a Spring endpoint to receive a HttpServletRequest object as a parameter will provide sufficient HTTP request information for the current request.

Depending on whether there is a proxy between the end-user client and the backend service communication:

• with proxy: use X-Forwarded-For and X-Forwarded-Port header values to resolve the IP address of the end user client as it is done here. When using proxies in HTTP communication, it is expected that the service forwarding the request fills these headers.
• without proxy: the remoteAddr and remotePort properties of the HttpServletRequest object represent the IP address of the end user client, no further resolving needed

Send the verify request to Infobip and handle the callback

Request body's deviceIp and devicePort should correspond with the resolved client's IP address (see the official documentation for more information about the Silent Mobile Verification request). The process of constructing the request can be found here.

Infobip should respond one of the three responses where JSON body contains:

• REDIRECT status with the request token and the device redirect URL
• OK status with the request token (see API flow diagram for Brazil clients, this case happens only if the verify request is being made for a Brazil (+55) number)
• ERROR status with the request token and an error object

Either way, the backend service should send a response to the end-user client containing the request token and optionally the device redirect URL.

Once the end-user client finishes the redirects with the network operator and Infobip, Infobip will send a callback request to the backend service's publicly exposed callback endpoint (implemented here, which was defined in the verify request. The callback endpoint should accept a POST HTTP request with a JSON object request body defined as (see the official documentation of the verify result):

Key	Type	Required	Description
result	enum	No	Request/verification result, either "VALID", "INVALID" or "ERROR"
token	string	Yes	Unique request identifier.
error	Error object	No	Information about occurred error. If there is no error this object is omitted.

Error object JSON body structure defined as:

Key	Type	Required	Description
id	integer	Yes	Identifier of the error code (see the official documentation of Infobip error codes).
name	string	Yes	Error code name (see the official documentation of Infobip error codes).
description	string	Yes	Information about occurred error.

Provide a polling endpoint to the end-user client

The result of the verify request that is provided on the callback endpoint should be persisted (implemented here), so that the polling endpoint has somewhere to check whether the result arrived when the end-user client requests it.