How it works

The request flow

When a service provider calls an Open Gateway capability, the request passes through several layers:

plaintext
Application → Aggregator → Apigee → API Manager → Capability Microservice
  • Application: The service provider’s app or system making the request.
  • Aggregator: An intermediary that bundles access to multiple operators under a single commercial agreement (e.g., GSMA OPF, a local aggregator).
  • Apigee: Google’s API gateway layer, responsible for traffic management, throttling, and initial authentication.
  • API Manager: Our central gateway. Validates scopes, tenant, and MSISDN before routing to the right capability.
  • Capability Microservice: The service that implements the specific CAMARA capability (Number Verification, SIM Swap, KYC, etc.).

Authentication types

Open Gateway supports three OAuth 2.0 authorization flows depending on the use case:

CIBA (Client-Initiated Backchannel Authentication)

Used when an application needs to act on behalf of a user, without redirecting them to a browser. The authorization happens at the network level — the operator authenticates the user silently based on their SIM. Typical for mobile-native flows.

Authorization Code

The standard OAuth 2.0 flow where the user is redirected to an authorization page to grant consent. Used when a browser session is available and the user interaction is acceptable.

JWT Bearer

A machine-to-machine flow where the application authenticates using a signed JWT instead of a user session. Used for server-side integrations where no end-user interaction is involved.