Application configuration

Entity meaning#

An integration application assembles clients/adapters for one product surface, points at an authorized backend and selects public authentication presentation. It does not become an embedded-wallet owner. A server-wallet service identity is separately configured, auditable and limited; it is never inferred from the application label or an end-user session.

This distinction prevents a dashboard label named “application” from being mistaken for an SDK resource with unsupported CRUD.

Bootstrap surfaces#

TypeScript browser core and React#

Browser bootstrap accepts only public values required to reach the application's own backend/auth proxy and initialize the UI adapter. Exact option names remain an implementation contract, but the boundary is fixed:

• public backend or proxy URL;
• public organization lookup context when the selected flow requires it;
• enabled login choices and public presentation metadata;
• allowed redirect/origin information already approved by the backend;
• an optional application-level authorization callback that receives one exact pending action and returns one bound response.

React provides a client-component context/provider around the same TypeScript client. It does not duplicate business methods or run during server rendering. The provider may call getProxyAuthConfig to obtain public authentication choices; unavailable configuration fails explicitly and cannot fall back to a broader login or wallet permission.

TypeScript, Python and Go servers#

Server construction supplies organization context and authorized server/service credentials through approved server-side custody. Python and Go remain server bindings. No server credential, event-verification secret, signing secret, session secret or provider client secret is serialized into browser configuration.

Verified method and explicit absences#

Organization OAuth client credentials are configuration-adjacent but are not application records. Their secure-backend get/list/create/update/delete contract is defined once in Frontend authentication and referenced from Organizations. No application CRUD or browser secret-provisioning method is inferred from those admin methods.

const authConfig = await browserCore.getProxyAuthConfig();
const server = createServerClient({ endpoint, organizationId, credential: serverCredential });

server = create_server_client(ServerClientOptions(
    endpoint=endpoint,
    organization_id=organization_id,
    credential=server_credential,
))

server, err := NewServerClient(ServerClientOptions{
    Endpoint: endpoint,
    OrganizationID: organizationID,
    Credential: serverCredential,
})

Constructor names are schematic target shapes, not installable packages. The public browser path never accepts serverCredential.

Failure and security behavior#

Configuration is versioned and validated before use. Missing endpoint, incompatible auth configuration, wrong organization context, disallowed origin, unavailable proxy or stale configuration produces a typed non-success and no user, session, wallet or policy effect. Public configuration never proves authorization. The backend rechecks the authenticated actor, organization, wallet access, policy and action-bound approval at each protected boundary.

Changing application presentation cannot enable a disabled authentication factor, weaken an organization policy, make a server-only method browser-safe or convert login into transaction consent. Cache use, if later accepted, must be bounded and tied to a configuration version and expiry.

Acceptance#

• Positive: each runtime can be initialized from its allowed configuration without inventing an application record.
• Positive: getProxyAuthConfig returns only public authentication settings and creates no session or authority.
• Negative: no generic application CRUD or unverified configuration method appears; hosted workload APIs are excluded; browser output contains no server secret.

See Frontend authentication, Users, and Organizations.