Guides

Authentication

Three kinds of caller, three kinds of credential: API tokens for your scripts, session cookies for the dashboard, and machine tokens for the agent.

API tokens

An API token is what scripts, CI jobs and your own tools use. Create one in the dashboard under Settings → API tokens, or with the API. It starts with ifl_ and is shown once.

Send it as a bearer token

curl https://api.infraflow.app/v1/orgs/acme/services \
  -H "Authorization: Bearer ifl_…"

A token belongs to one workspace. Calls to another workspace's paths answer 404, as if it did not exist.
A token has a role, chosen when it is created, and can do what a person with that role can.
It can be given an expiry, and revoked at any time; a revoked token answers 401 unauthenticated at once.
Only its hash is stored. A lost token cannot be shown again: revoke it and create another.

Roles

Every endpoint names the least role it accepts. A lower one answers 403 forbidden.

Role	Can
`viewer`	Read everything in the workspace except secrets: services, logs, requests, events, buckets and their listings.
`member`	Create and change resources: deploy, set variables, add tunnels and machines, write objects, edit the WAF policy.
`admin`	Also manage members and API tokens, delete buckets and services, and change workspace settings.
`owner`	Also delete the workspace and change who owns it. Not available to API tokens.

The dashboard signs people in and keeps an ifl_session cookie: HTTP-only, SameSite=Lax, valid thirty days. The endpoints under /v1/auth, /v1/me and /v1/admin accept only this cookie. They exist for the dashboard; prefer a token for anything automated.

With two-factor on, signing in with a password yields a session that is not usable until POST /v1/auth/mfa has been given a code. Until then calls answer 401 mfa_required.
Requests that change something and carry an Origin header are refused unless that origin is the dashboard's: a page on another site cannot act with a visitor's session.

Confirming identity for secrets

Reading a secret back, such as the values of a service's variables, asks a dashboard session to prove again who it is. Without a recent confirmation the call answers 403 confirmation_required.

GET /v1/auth/confirm says whether the session is confirmed and which methods the account has: a passkey, a two-factor code, or the password.
POST /v1/auth/confirm with password or code, or the two calls under /v1/auth/confirm/passkey, confirm it for ten minutes.

API tokens are not asked: they are made to work unattended, and a token with the member role can read variables directly.

Machine tokens

A machine that runs the agent has its own token, starting with ifm_, given when the machine is added and replaceable at any time. It opens only the four routes under /v1/machine: what the machine should serve, exposing or removing one of its own services, and the ticket that lets it connect a tunnel. It cannot read or change anything else.

What the agent asks every few seconds

curl -X POST https://api.infraflow.app/v1/machine/sync \
  -H "Authorization: Bearer ifm_…" \
  -H "Content-Type: application/json" \
  -d '{"serving": true}'

Object storage credentials

Objects are read and written with the S3 protocol, not this API. Each bucket has access keys of its own (an access key id and a secret, optionally read-only), created under Object storage. For a browser or a one-off transfer, POST …/objects/sign returns URLs that already carry a signature and need no key.