@veap/auth

Inspected version: 0.1.1 · Source →

Authentication and identity services for Veap: users, sessions, password reset, email verification, role/permission checks, cryptographic adapters, validation schemas, and Next.js Server Actions.

Entry points#

The package manifest exports ., /client, /server, /actions, /validation, /models, /migrations and /package.json.

• Root exports actions, client hooks, common types, crypto, password, provider, RBAC, session, user, validation and verification APIs.
• /client exports the React auth context/hooks.
• /server exports root APIs and server-oriented crypto/actions.
• /actions exports the action module.
• /validation exports Zod schemas and inferred input types.
• /models exports auth model definitions.
• /migrations exports auth migration definitions.

Keep the root/client imports out of inappropriate runtime boundaries. Never send server secrets or raw password/session records to client code.

Provider and initialization#

AuthServiceProvider accepts an optional container and optional AuthConfig. Its config supports a partial routes map and autoMigrate (default enabled when the database is initialized). Register database before auth:

import { Application } from "@veap/kernel";
import { DatabaseServiceProvider } from "@veap/database";
import { AuthServiceProvider } from "@veap/auth";

const app = Application.configure()
  .use(DatabaseServiceProvider)
  .use(AuthServiceProvider)
  .create();

await app.bootstrap();

The provider binds crypto ports, repositories and domain services, binds the shared auth context, can register route rewrites when a router service is available, and may run auth migrations during boot. For production, coordinate migrations as an explicit deployment step rather than relying on every runtime instance to migrate concurrently.

Default route configuration#

DEFAULT_AUTH_ROUTES defines:

These are route configuration values and rewrite targets; the package does not by itself create the corresponding pages in a Next.js app.

Server Actions#

The inspected action module exports:

• signIn(data: LoginInput)
• signUp(data: RegisterInput)
• finalizeLogin(userId, flags)
• signOut()

The actions resolve AuthService from the kernel container and return standardized Result responses through ok() / handleActionError(). AuthResponse can represent success, a required challenge, or an error; callers must handle all cases rather than assuming a successful login.

Validation#

The validation subpath exports loginSchema, registerSchema, forgotPasswordSchema, resetPasswordSchema, verifyEmailSchema, totpSetupSchema, totpVerifySchema, backupCodeSchema, verifyEmailInput, and inferred types such as LoginInput and RegisterInput.

The inspected registration schema uses username, email, password and terms. Passwords have a minimum length of eight in the schema. Do not infer that a field named name is interchangeable with username.

Domain capabilities#

The package exports user, session, RBAC, password-reset and email-verification services/facades and their model types. Core model names include User, Session, Role, Permission, PasswordResetSession and EmailVerification.

FullUser includes roles and permissions. RBAC types represent role and permission names as strings, so define and validate your application's permission vocabulary deliberately.

Security review checklist#

• Configure encryption keys and password policy for your threat model.
• Use HTTPS and secure cookie/session settings in the web integration.
• Add rate limiting and abuse controls around login, registration and recovery flows.
• Avoid user enumeration in reset/verification responses.
• Do not log credentials, recovery codes, verification codes or session secrets.
• Verify session expiration and invalidation behavior with integration tests.
• Test all AuthResponse branches, including challenge-required flows.