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.