Server to Server Validation Approach
The How It Works section outlines the concept of the server to server approach. There are a number of distinct steps to use this approach:
- Use the DeviceAssure client library to collect device data. The data is provided to the calling client application.
- The collected data should be transmitted in a secure manner to a suitable server.
- The server makes a request to the DeviceAssure service with the collected data and client HTTP headers.
- The validation results are returned directly to the server and not to the client.
Details on how to call the DeviceAssure REST API for device validation is described in the following sections.
Calling the DeviceAssure REST API
DeviceAssure provides a simple REST API that may be used to validate the data collected by the DeviceAssure client libraries. The following sections assume that the data has already been collected by the client and securely transmitted to a suitable server.
The collected device data must be sent as a POST request along with a number of client HTTP headers.
API URLs
The DeviceAssure service is geo-distributed and will automatically use the nearest API server for a request. There are a number of API endpoints provided for fallback purposes.
The API endpoint URLs should be called in the order specified. If an error or timeout occurs then api2 should be called and finally api3. Please see the Error Codes section.
| Priority | Endpoint |
|---|---|
| Primary | https://api1.devicevalidation.io/check |
| Fallback 1 | https://api2.devicevalidation.io/check |
| Fallback 2 | https://api3.devicevalidation.io/check |
A licence key must be included in a URL parameter called licence. This key is provided as part of the on-boarding process. The request will not be accepted if the provided licence key is not valid.
An example of this is below:
Required HTTP Headers
The client application sends a number of HTTP headers along with the device data. Some of these are required by the DeviceAssure Service and should be extracted and sent along with the device data to the DeviceAssure REST API. These HTTP headers must be prefixed with DV-.
Android Library HTTP Headers
Forwarded Client HTTP Headers
These HTTP headers must be extracted from the client request and forwarded to the DeviceAssure API with the DV- prefix.
| HTTP Header | Required | Description | Example |
|---|---|---|---|
DV-client-ip | Yes | The client IP address. Commonly found in the client-ip header but may be present in other headers depending on your server configuration. | DV-client-ip: 89.101.149.145 |
DV-user-agent | Yes | The client user-agent header. | DV-user-agent: Mozilla/5.0 (Linux; Android 4.0.4; ...) |
Additional Required HTTP Headers
These HTTP headers should be included directly in the request to the DeviceAssure API.
| HTTP Header | Required | Description | Example |
|---|---|---|---|
accept | Yes | The accept header for the response format. | accept: application/json;charset=UTF-8 |
Web Library HTTP Headers
In addition to DV-client-ip, all client request HTTP headers must be included, prefixed with DV-.
| Original HTTP Header | Send As | Example |
|---|---|---|
accept-language | DV-accept-language | DV-accept-language: en-US,en;q=0.9 |
accept-encoding | DV-accept-encoding | DV-accept-encoding: gzip, deflate, br |
user-agent | DV-user-agent | DV-user-agent: Mozilla/5.0 ... |
| (all others) | DV-{header-name} | Prefix all client HTTP headers with DV- |
Note: All client request HTTP headers must be forwarded and prefixed with
DV-.
Additional Recommended Request Headers
For improved request tracing, reliability, and support, the following optional headers can be included. The values are extracted from the payload object returned by the client library.
| Header | Value | Description |
|---|---|---|
DV-DeviceAssure-ID | payload.info.requestId | Unique identifier for this verification session, useful for correlating retries across failover URLs |
DV-DeviceAssure-Variants | payload.info.variants | Session variant identifiers from the client library |
DV-DeviceAssure-Version | payload.info.version | Version of the client library that collected the data |
DV-DeviceAssure-Attempt | 0, 1, 2 | Tracks which API endpoint is being called. Start at 0 for the primary endpoint, increment on each failover |
// Extract from the payload received from the client
const headers = {};
headers['DV-DeviceAssure-ID'] = payload?.info?.requestId;
headers['DV-DeviceAssure-Variants'] = payload?.info?.variants;
headers['DV-DeviceAssure-Version'] = payload?.info?.version;
let attempt = 0;
for (const url of deviceAssureApiUrls) {
headers['DV-DeviceAssure-Attempt'] = attempt;
// ... make the API call with these headers
attempt++;
}
Making the Request
The data collected from the end user device must be sent in its entirety, in JSON format, within the body of a POST request.
Request Requirements:
| Component | Requirement |
|---|---|
| Licence key | Include as URL parameter ?licence=<LICENCE_KEY> |
| Client HTTP headers (Android) | Include DV-user-agent and DV-client-ip |
| Client HTTP headers (Web) | Include all client HTTP headers prefixed with DV- |
| Body | Full unaltered JSON data collected from the client device |
| Method | POST |
Sample Request
A sample DeviceAssure Android library request is provided below. The body of this request is for example purposes only. In practice, the full unaltered JSON data collected from the client device is required.
POST /check?licence=<LICENCE_KEY> HTTP/1.1
Host: api1.devicevalidation.io
DV-user-agent: <client-user-agent>
DV-client-ip: <client-ip-address>
accept: application/json;charset=UTF-8
content-length: <length>
{
"info": {
"version": "2.0.3",
"date": "2020-04-04T15:50+0000"
... more data ...
},
"data": {
"build": {
"manufacturer": "Samsung",
"model": "GT-N9500",
... more data ...
},
"gpu": {
"renderer": "PowerVR SGX544 MP3"
}
... more data ...
}
}
Further information and example code can be found in the Android Server to Server and Web Server to Server guides.
Validation Response
The DeviceAssure REST API will return a validation result back to the calling server. This response is in JSON format. Please see the Service Responses section for further details.
See Also
- Web Server to Server - Web library S2S integration
- Android Server to Server - Android library S2S integration