Authorization model and trust chain

Authorization is evaluated on the server. UI hiding is not authorization, and CORS is not authorization. A missing, ambiguous, inactive, wrong-tenant, or under-scoped context must fail closed.

Human merchant authorization

Owner, Admin, and Staff describe what a person may do for a tenant. Owner and Admin may install or revoke an app in the current Marketplace lifecycle. Staff does not become authorized merely because an installation control is hidden or exposed in the browser.

Platform-staff authorization

Support and Super Admin are platform roles. Support is read-only for Marketplace review. Super Admin may make review and publication decisions. Neither role is an app permission, an OAuth grant, or a merchant app credential.

App authorization

App authorization consists of the app identity, an active installation, the exact installed app version, the tenant, and the OAuth scopes granted to that installation. A token is accepted only through this chain:

App → Installation → Tenant → Exact Version → Granted Scopes

Relationships that do not exist

• Owner is not an OAuth scope.
• Admin is not an OAuth scope.
• Support is not an app permission.
• Super Admin is not a merchant app credential.
• A registered scope is not a public API operation.
• A published newer version is not an automatic installation upgrade.

Server-side enforcement

Send access tokens only from a trusted server. The public API resolves the token, active installation, tenant, app, and required scope before a tenant-filtered query. Never trust a tenant identifier, role label, scope list, or installation state supplied only by browser code.