Managed application identity

Status: the controlled Shared step 6 profile is validated in this private source checkpoint. The validation ledger owns evidence and limits. This does not accept customer-operated installation or independent regional identity failover.

Ownership and compatibilityCopy Anchor Link

The identity module composes pinned Better Auth 1.7.14 with PostgreSQL through its native adapter. Package pins and inferred client/plugin types are authoritative in the module and SDK manifests. The Go resource coordinator registers exact scoped clients through a protected installation socket. Normal service startup validates existing schema; migration runs separately with an owner credential.

Application login is separate from infrastructure management authentication. A registered consumer supplies technical scope and configured policies. This module does not require Claywork accounts, signup rules or product role names.

Application useCopy Anchor Link

Use createAuthClient from @astrogate/sdk/browser with the validated identity binding's endpoint. Its signIn.email, getSession and signOut methods are native Better Auth methods and retain their native result/error types. createApplication({auth, storage}) composes that same client with optional scoped file access; it does not introduce another login implementation.

The experimental installation permits email/password login and exact registered callbacks. Supported native plugin methods depend on the installed profile. An inferred client method is not permission to expose its server route. Administrative routes and unused native InstantDB login/storage paths remain blocked.

For a hosted request, the gateway validates the configured authority cookie and independently checks project/environment grants before issuing short-lived service sessions. Server handlers read request-scoped sessions through serviceSessionsFromHeader; never put a user's session into a shared global client. Browser configuration contains public bindings, not native issuer, PostgreSQL or S3 credentials.

Sessions, changes and recoveryCopy Anchor Link

• Cookies are secure, host-only and tied to registered origins. A shared parent domain grants no cross-environment permission.
• Logout, disabled subjects and revoked grants invalidate derived file/database access. Existing realtime connections are revalidated within the installation's declared deadline.
• Changing Better Auth's active signing secret requires reauthentication in this pinned version. Versioned encryption secrets do not imply overlapping cookie signatures. Stable native subject IDs must survive rotation and restore.
• An application move may retain the same explicitly registered shared authority. This is a declared dependency, not an autonomous identity instance in the destination region.
• Operator recovery needs the native account/client database and independently protected versioned signing/encryption keys. A metadata dump or an app artifact alone cannot recover login.
• Shared account tables, global keys and sessions are not customer export material. Subject mapping or federation/reauthentication requirements must be explicit. Unsupported identity dependencies block a complete-exit claim.

The module's real PostgreSQL lifecycle tests and connected Next.js/Vite browser tests cover registration, native session behavior, scope and revocation. Follow secret lifecycle, identity and safe updates for a changed engine/plugin/schema combination. Preserve upstream licenses and notices; this guide does not change distribution rights.