Authentication

Machines get API keys. Agents acting for a signed-in person get OAuth. Both arrive as a bearer token and both pass through the same authorisation as a person in the app.

API keys

A key belongs to exactly one organisation. An organisation key acts for the organisation with the permissions chosen when it was minted, and keeps working whoever leaves. A personal key acts as its owner, can never do more than its owner may do today, and stops the moment their membership ends. Keys are minted under Organisation settings, Integrations, shown once, and revoked in a click.

Authorization: Bearer <key>

Permissions

Permissions are noun.verb names from one registry, the same one the product gates on: project.view, asset.download, workorder.create, audit.view, org.view and the rest. A refusal says which one was missing:

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope", scope="audit.view"

OAuth 2.1 for agents

An MCP client or a connector obtains an access token through sign-in (authorization code with PKCE) and sends it as the bearer. Tokens are bound to one person, one organisation and this platform's own address, and their scopes are permission names. The protected-resource metadata at /.well-known/oauth-protected-resource names the authorization server.

Single sign-on for people

People sign in on Final Frame's own card with a password and an authenticator, or through their company's Okta, Entra ID or Google Workspace once an administrator has proved the domain under Organisation settings, Sign-in. Sign-in proves who somebody is; a membership is what grants access.