Key Components

In this section, you’ll find a high-level overview of the components involved in integrating with Bespot Gatekeeper and how they exchange information. The following diagram offers a visual representation, and each component is detailed afterwards. By reviewing this overview first, you’ll gain the necessary context before integrating Bespot’s SDKs and services.

Bespot Auth Server

The Auth Server issues access tokens based on the Client Credentials Flow, as defined in OAuth 2.0 (RFC 6749, Section 4.4). It is used in the server-to-server verification flow, granting the Client Server access to the API Server’s endpoints, specifically the /api/s2s/verify endpoint. The access tokens are in the form of JWTs (JSON Web Tokens) following the RFC 7519.

Bespot API Server

The API Server exposes all available endpoints. Any entity that needs to consume these endpoints must be first authorized. The access token (JWT), previously acquired from the Auth Server, must be provided in the Authorization HTTP header with the “Bearer ” prefix for the resource to be accessible. Otherwise, a 401 Unauthorized HTTP error is returned.

Client Server

This is the customer’s Client Server. It receives verification requests from the customer’s frontend applications (Web, iOS, Android). These requests include the Action and Ticket information, which is then used as the body payload for the /api/s2s/verify HTTP endpoint of the API Server. Following successful verification of the Policy Action based on the Ticket information by the API Server, the Client Server informs the frontend applications that the verification is completed, allowing the transaction to proceed.

The Ticket is an encrypted string that can only be decrypted by the API Server and contains all information regarding the Detection Results, the Policy Action, and the timestamp information that the frontend applications initially received.

Bespot Web SDK

The Web SDK incorporates functionality for performing detections on the Web Browser, communicating with Bespot’s API Server, and receiving the Policy Action. The Web SDK is the library to be used, as a dependency, in the customer’s application to provide the Policy Action.

Bespot iOS SDK

The iOS SDK incorporates functionality for performing detections in iOS devices, communicating with Bespot’s API Server and receiving the Policy Action. The iOS SDK is the library to be used, as a dependency, in the customer’s iOS mobile application to provide the Policy Action.

Bespot Android SDK

The Android SDK incorporates functionality for running checks in Android devices, communicating with Bespot’s API Server and receiving the Policy Action. The Android SDK is the library to be used, as a dependency, in the customer’s Android mobile application to provide the Policy Action.

Client Web App

This is the customer’s web application where Bespot’s Web SDK is used as a dependency and provides the Policy Action.

Client iOS App

This is the customer’s iOS application where Bespot’s iOS SDK is used as a dependency and provides the Policy Action.

Client Android App

This is the customer’s Android application where Bespot’s Android SDK is used as a dependency and provides the Policy Action.