Skip to main content
The Binarly Transparency Platform API accepts Bearer tokens from two authentication methods. Both use the same Keycloak token endpoint, but they differ in who the token represents and how access control applies to it. Tokens from both methods expire after 30 minutes.

​
Access control for user tokens

A user token carries the permissions of the user who requested it. The API enforces the same roles that apply in the dashboard: organization roles, team roles, and product and ruleset roles, whether assigned directly, through a team, or at the organization level. When a user token lacks the permission for a request:
  • List endpoints, such as listing products, return only the resources the user can access.
  • A GET request for a single resource the user can’t access returns 404 Not Found, as if the resource didn’t exist.
  • Other requests, such as uploading an image or starting a scan, return 403 Forbidden with the permission that was missing.
For example, a user with the Product Viewer role on a product can read its images and findings through the API, but can’t upload or scan images in it. See the product permissions table for the full list.

​
Access control for M2M tokens

M2M clients have full administrative access. RBAC doesn’t apply to M2M tokens yet. An M2M token can call every API endpoint and read or change every product, image, ruleset and team in your organization, regardless of the roles configured in the dashboard. You can’t restrict an M2M client to specific products or permissions.
This applies to every M2M client, including clients created on-premises in Keycloak. Roles or scopes assigned to the client’s service account in Keycloak don’t limit what the client can do in BTP. Until scoped M2M access is available, treat a client secret like an Organization Admin password:
  • Store the client ID and secret in your CI/CD platform’s secret store, never in source code or build logs.
  • Limit who can read the secret and who can edit pipelines that use it.
  • Create a separate API client for each pipeline or system, so you can revoke one without affecting the others.
  • Rotate the client secret regularly, and immediately if you suspect it was exposed.
  • If a workflow needs access limited to specific products, use user authentication with a dedicated BTP user that has only the roles the workflow needs.

​
On-premises deployments

RBAC is off by default on on-premises installations. Until you enable it, user tokens aren’t restricted by roles either, and access is managed only in Keycloak. To turn on RBAC for the dashboard and the API, see Role-Based Access Control (RBAC) in the on-premises configuration guide. M2M tokens have full administrative access whether RBAC is on or off.