Description
Authentication Flow Overview
In the authentication flow, the Licensee (operator) acts as the entry point and gateway for the Player. The primary challenge is to securely transfer the player’s session from the Licensee platform to the Game Provider environment without exposing sensitive credentials.
This section defines how the Licensee is authenticated, and how Service-to-Service (S2S) authentication is performed between the Game Provider and the Licensee, ensuring that all incoming requests originate from an authorized partner.
Authentication Logic
When the Game Provider receives a request, the validation process ensures that the request can be trusted as coming from a legitimate Licensee:
- Verify request origin: Only a Licensee that possesses the shared client secret can generate a valid signature. The Game Provider uses this to confirm the request source.
- Ensure request integrity: The signature is calculated based on specific fields in the request. Any modification to signed content during transmission will cause verification to fail.
- Prevent request forgery: Even if an attacker intercepts the HTTP request, they cannot regenerate a valid signature without the client secret.
- Prevent replay attacks: With dedicated HTTP headers, requests can be time-bound and duplicate submissions can be detected.
Supported Authentication Mechanisms
To accommodate different security requirements and technical capabilities, several authentication methods are provided:
Asymmetric Signature
Uses a public/private key mechanism for request signing. The Licensee signs requests using its private key, and the Game Provider verifies them using the corresponding public key. This model does not require sharing a secret key and is suitable for scenarios with higher security or audit requirements.
Symmetric Signature
Both parties share a CLIENT_SECRET. Requests are signed using HMAC-SHA256. The Game Provider recalculates the signature using the same key for verification. This approach is simpler to implement and has lower computational overhead, making it suitable for high-frequency service-to-service requests.
API Key
The Licensee is assigned an API_KEY as an identification credential, which is sent via HTTP headers. This method has the lowest integration cost but only provides basic client identification. It is typically used in conjunction with IP Address whitelisting or additional protection mechanisms.
| Authentication Method | Security Characteristics | Supported Algorithms |
|---|---|---|
| Asymmetric Signature | No shared secret required; supports request integrity verification and full traceability | ECDSA-SHA256 |
| Symmetric Signature | Requires shared client secret; verifies request origin and integrity |
HMAC-SHA256 |
| API Key | Provides client identification only; no signing or integrity protection | N/A |
Recommended Approach and Compliance
Recommended Authentication Method
We strongly recommend using asymmetric signatures with ECDSA-SHA256 for request authentication. All requests must be digitally signed by the Licensee using its private key. The corresponding public key is registered with the Game Provider for verification purposes only.
Under the asymmetric cryptography model, the Licensee retains full control of its private key at all times. The Game Provider only stores the corresponding public key for verification, and therefore cannot technically forge or impersonate requests from the Licensee.
- Audit compliance: Each request is protected by cryptographic signatures, ensuring authenticity and non-repudiation.
- Industry standard: ES256 (ECDSA P-256 with SHA-256) is widely adopted in financial services, OpenID Connect, and modern API security architectures.
- Ease of integrationMature libraries and online verification tools (such as CyberChef1) are available across major programming languages, reducing integration risk and simplifying debugging.