Better Auth configuration
Sigma's issuer composes Better Auth with the Sigma provider, OAuth provider, JWT, organization, passkey, two-factor, email OTP, device authorization, and Agent Auth plugins. Optional social providers and delivery services depend on deployment configuration.
Integrating an application
Use the client/server callback exports described in integration. sigmaProvider() is issuer-side code. Adding it to your application is not the equivalent of configuring a social-provider URL.
The Next session adapter needs your configured, database-backed Better Auth instance. Keep database schema and account-linking policy compatible with the installed Better Auth and Sigma package versions. Do not copy internal table names or migrations from an older plugin release.
Running the issuer
The production server composes configuration in lib/auth-config.ts and runtime services in lib/auth.ts. Social providers belong in Better Auth's top-level socialProviders option. Sessions are persisted in the database with secondary storage and a five-minute encrypted cookie cache.
Email/password sign-in is enabled with email verification required. It is distinct from the backup password used locally. Client identity signatures supplement this account system; they do not mean every login path is passwordless.
Versions and upgrades
Use the repository lockfile to determine the actual deployed dependency version. A ^ manifest range and a claim to use “latest” do not establish which code is running. Better Auth's current OAuth provider documentation describes upstream capabilities; the hosted Sigma hooks and feature flags can impose additional requirements.
Test session cookies, OAuth state/PKCE, client signatures, refresh, account linking, and recovery after dependency upgrades. Follow the repository's migration runner and staging promotion workflow instead of running ad hoc schema commands against production.