Constructive Auth

Constructive Auth

Configure identity, authentication, and session behavior. This skill owns auth semantics and settings; constructive-blocks owns the Authentication feature-pack UI, its standalone host contract, and the Console module's endpoint, session, discovery, and adapter boundaries.

When to Apply

Use this skill when:

• Configuring sign-up, sign-in, recovery, magic link, OAuth, passkey, or phone behavior.
• Configuring MFA, backup codes, trusted devices, or device approval.
• Configuring cookie auth, anonymous sessions, CAPTCHA, cross-origin behavior, or rate limits.
• Linking identities or resolving account collisions.
• Understanding auth operation results, session claims, and service settings.

For product UI, activate constructive-blocks and install the Authentication pack or its Console module. Sign-up, sign-in, recovery, and account management are acceptance scenarios within that pack, not separate install units.

Runtime Boundary

For the Console auth module or custom auth client, the host must supply the tenant's explicit semantic auth endpoint. A standalone Authentication pack receives already-loaded resources and semantic actions through its host contract, so it does not resolve that endpoint itself. In Blocks/frontend/application code, never construct an auth-<database> hostname, derive a sibling route from the data endpoint, or send a bearer token to an inferred origin — endpoint discovery is the provisioning/harness layer's job (that layer derives and pins the per-DB endpoints and hands them to the app via env/host contract).

Use the Blocks auth adapter for Console Kit. A standalone Authentication pack receives its resources, policy, actions, errors, and view state from the host and performs no endpoint or session discovery. For custom domain code, create an endpoint-scoped client from the explicit descriptor and keep credentials in the host session boundary. Do not place bearer tokens in component props, URLs, a process-wide client, or the Console Kit Zustand store.

See auth-flow.md for the custom-client boundary and acceptance scenarios.

Auth Settings

app_settings_auth (private auth schema, no generated ORM model — provisioning-time settings; see the SDK-gap note in the reference) controls authentication behavior exposed by the installed backend modules:

• MFA: require_mfa, supported factors, backup codes, step-up window, and challenge expiry.
• Anonymous sessions: allow_anonymous_sessions for explicitly designed pre-auth use cases.
• CAPTCHA: enable_captcha and the public site key.
• Cookie auth: enable_cookie_auth for browser session transport.
• Cross-origin behavior: service-level origin and token settings.
• Rate limits: installed rate-limit capability and meter configuration.

See auth-settings.md for the settings reference.

Devices

Device tracking can combine trusted-device recognition, MFA on a new device, and an approval gate. Treat the returned device token as a separate opaque credential from the access token.

See device-settings.md for the composition matrix and service-settings.md for service-level routing, RLS, WebAuthn, and public-key configuration.

Service Settings and Request Protection

db.databaseSetting (one row per database) and db.apiSetting (per-API override) carry the feature flags (enableRealtime, enableBulk, enableBilling, enableIntrospection, …) and the request-protection bounds (statementTimeoutMs, maxConcurrentRequests, maxQueueWaitMs, rateLimitRpm, rateLimitBurst, maxQueryDepth, maxQueryCost, maxPageSize, maxRequestBytes, lockTimeoutMs, idleInTransactionTimeoutMs). Bounds are a lower-only cascade: null inherits the platform default, an API row may only tighten the database row, and the platform ceiling is a code constant. enableIntrospection defaults to true — turning it off is the opt-in.

Passkeys: db.webauthnSetting (RP config) and auth.webauthnCredential (a user's credentials) are ORM models; the register/sign-in ceremonies have no generated operation (SDK gap).

See service-settings.md for the field tables and update examples.

Identity Linking

Identity linking associates multiple authentication providers with one user while preserving collision and primary-method policy. allow_link_by_email controls whether a matching provider email may offer linking; enforce_primary_auth_method controls whether sign-in is restricted to the user's primary method. Both toggles are provisioning-time settings with no generated ORM field (SDK gap); the client-callable operation is auth.mutation.linkIdentity, and auth.identityProvider exposes enabled/displayName per provider.

See identity-linking.md for operation behavior and error handling.

References

Cross-References

• constructive-blocks — Authentication feature-pack installation and runtime.
• constructive-security — authorization, RLS, and step-up policy.
• constructive-entities — memberships and invitations.
• constructive-principals — API keys and delegated identities.