A shared secret issued by the platform when you create a TMF Application. Simpler to set up but the secret must be kept secure and never exposed in client-side code.

How to get it

During the TMF931 onboarding flow, create an Application via the TMF Integration page or API. The platform returns a clientSecret (also visible as "Generated Client Secret" in the MBAPI TMF Integration page). Store it securely — it is only shown once.

How to use it in a token request

Include client_id and client_secret as form parameters:

You sign a short-lived client assertion JWT with your own private key. The token server verifies it using the public key from your registered JWKS endpoint. No secret is transmitted — more secure and recommended for production.

Setup steps

Client assertion JWT structure

Build and sign this JWT with your private key:

Token request with private key JWT

What: Your application signs a JWT assertion that identifies the subscriber (phone number). No user interaction is needed — fully machine-to-machine.

When to use: KYC, Sim Swap, Location Retrieval, Number Recycling, QoD, NV2, and most other CAMARA APIs.

Flow: Sign a JWT with the subscriber's phone number as sub → exchange at /token → use returned access_token to call the API.

JWT bearer assertion payload

Token request

What: Triggers a network-side authentication challenge to the subscriber's SIM. For consent-based flows, the subscriber receives an SMS with a link to the privacy portal. The client polls until authorization is granted.

When to use: Location Verification v1 / v2 (Germany), Device Roaming Status (Germany production).

Flow: POST to /bc-authorize with the subscriber hint → the subscriber follows the SMS link to the privacy portal and grants consent → receive auth_req_id → poll /token every few seconds until authorization is granted.

Step 1 — Backchannel authorization request

Step 2 — Poll token endpoint every interval seconds

What: The subscriber authorizes via a browser redirect. For consent-based flows, the subscriber is redirected to the privacy portal to grant consent, then redirected to the registered redirect URI with an authorization code to exchange for a token. For network-based flows (on cellular), this can happen silently without user interaction.

When to use: Number Verification v1, QoD (network-based on cellular).

Flow: Redirect user to /authorize → subscriber grants consent in the privacy portal (or authorizes silently on-net for network-based flows) → network redirects back with code → exchange code for token at /token.

Step 1 — Build the authorization URL and redirect

Step 2 — Network redirects back with code

Step 3 — Exchange code for token

What: Pure machine-to-machine. The token is scoped to the application itself — no subscriber identity.

When to use: Health check endpoints, NV2 health, some admin flows where no subscriber context is needed.

Token request

CIBA: The subscriber receives an SMS containing a link to the privacy portal. They open the link and grant consent there while your application polls the token endpoint. When consent is granted, the polling request returns an access token.

Authorization Code: Your application redirects the subscriber to the privacy portal. After the subscriber grants consent, the privacy portal redirects the browser to your registered redirect_uri with an authorization code. Exchange that code at the token endpoint for an access token.

Consent lifetime and revocation: All consent is set up as valid until revoked. To revoke consent, the subscriber returns to the privacy portal and turns off the relevant consent there.