Authentication

To access CAF resources using REST API, you will first need a JWT token. This is a token that CAF provides for authorization and is used by the client when making each API call.

A token is a secret that only the client knows. Like Basic authentication, token-based authentication is only considered secure if used together with other security mechanisms such as HTTPS/SSL.

It is possible to define which scopes the tokens will have access and which actions it can execute in that scope. Use some token that do not have the required permissions to access a resource will end up in a 403 "Forbidden" response, so you must be careful when set your token's permission by verifying which permissions are mandatory for each available resource.

You can create as many tokens as you need, so we recommend setting the minimum permissions necessary for each token.

Account users with appropriate permissions will be able to create tokens on the Trust Platform by following the below steps:

Getting your access token

Never share your API credentials with anyone, even CAF Support

Example request headers:

{
    "Authorization": "Bearer $CAF_TOKEN"
}

All calls to the API are authenticated and must have the token next to Bearer prefix in the Authorization header of the request. Calls with a missing or invalid access token will return code 401 "Unauthorized".

Best practices for token-based authentication

To ensure a secure and reliable integration when using token-based authentication with our service, follow these recommended practices and avoid common pitfalls.

✅ Recommended practices

Practice	Description
Generate and sign tokens on the server	Always issue JWTs from your trusted backend system to avoid exposing signing keys.
Use HTTPS for all communications	Prevent man-in-the-middle attacks and ensure encryption in transit.
Monitor token usage and behavior	Implement logging and monitoring to detect abnormal or suspicious activity.

❌ Unsafe practices

Practice	Risk
Generating tokens on the frontend	Exposes your signing keys and compromises the entire authentication system.
Storing signing keys or secrets in frontend/mobile apps	Secrets in client-side code can be extracted and misused.
Hardcoding secrets in version-controlled code	Secrets in code repositories can be leaked or accessed by unauthorized users.

Security tip

Never expose your secrets, private keys, or JWT signing credentials on the client-side. Always treat tokens and secrets as sensitive data and follow the principle of least privilege.

Important Notice about Integrations

To ensure the stability and security of our services, it is mandatory to implement integrations with Caf APIs exclusively via backend/server-side, as frontend calls (via browser or client-side) may be blocked by our systems when multiple IPs or browser user agents are detected. Furthermore, client-side integrations expose authentication keys to the risk of leakage and malicious use, which may lead to unauthorized resource consumption and additional charges. Authentication keys found to be used in incorrect implementations will be immediately deactivated.

We always recommend: (1) implementing on the backend, (2) using proper headers and authentication, and (3) never exposing credentials on the client-side. Please refer to our documentation for details or contact our technical support team.