Authentication & Security Protocols

Closed alpha testing

Access to the API is secured through a Dual-Token Identity System, designed to separate public client identification from authorization privileges. This allows for safe quota management and key rotation without service interruption.


1. Identity & Access Management (IAM)

Every secured transaction requires two distinct credentials:

🎫 A. Public Client Key

  • Header: X-API-Key

  • Purpose: Identifies the project environment (Live/Test).

  • Function: Enables the API Gateway to apply Rate Limiting policies, manage quotas, and route traffic to the appropriate Service Tier before resource-intensive processing begins.

🗝️ B. Secret Access Token

  • Header: Authorization: Bearer <secret_key>

  • Purpose: Authorizes the specific operation and validates access rights.

  • Security Mechanism: The system verifies this token using salted cryptographic hash comparison. The Secret Key is never stored in plain text within the database. Compromise of the database will not yield active credentials, as the original key cannot be reconstructed from the hash.


2. Payload Security (Zero-Knowledge)

For high-security endpoints, the platform enforces a Zero-Knowledge Transmission policy.

  1. Client-Side Encryption: Before transmission, the Client SDK packages sensitive data (images, metadata) into a secure JWE (JSON Web Encryption) container using the platform's Public RSA Key.

  2. Secure Transport: The API receives only the encrypted binary string. Intermediaries (Proxy servers, ISPs) possess no technical capability to inspect the request content.

  3. Secure Processing: Decryption occurs strictly within a Secure Execution Environment, utilizing private keys managed by the Google Secret Manager.

Last updated