Documentación

Authentication

FeatureAuth systemProviders and protection

Fast Unicorn uses NextAuth v5 with Prisma and JWT sessions.

Authentication is split across provider configuration, protected procedures, route boundaries, and reusable service logic so the app can support both standard and custom auth flows without collapsing everything into one file.

Need implementation details?

This page is the feature overview. For step-by-step changes, continue with Configure Auth.

What this feature includes

Provider configuration

OAuth and credentials-based sign-in are configured through the auth layer instead of being scattered through route files.

Protection boundaries

Route-level protection and API-level procedure guards work together to control authenticated access.

Custom auth flows

Sign-up and password recovery use routers and services so they can grow without bloating the provider config.

Providers

The current auth configuration enables:

  • Google OAuth
  • Credentials sign-in with email and password

Provider setup lives in src/server/auth/config.ts.

Main files and folders

  • src/server/auth/config.ts: Provider setup and session callbacks.
  • src/server/api/trpc.ts: Public, protected, and admin procedures.
  • src/server/api/routers/customAuth.ts: Sign-up and recovery procedures (including code generation, throttling, and expiration).
  • src/features/auth/: Reusable auth UI forms and components.
  • src/app/[locale]/auth: Route-level auth UI such as sign-in and sign-up.
Session and access

Session shape

The session is extended to include:

  • user.id
  • user.role

These fields are injected through the jwt and session callbacks.

That makes authorization and route protection easier because the app can rely on stable user identifiers and roles in both UI and server logic.

Credentials flow

The credentials provider:

  • validates input with Zod
  • loads the user from the database
  • verifies the hashed password with argon2
  • returns a normalized session user object

This flow is useful when the product needs native email/password access in addition to social sign-in.

Route protection

There are two main protection layers:

  • dashboard-level protection in src/app/[locale]/dashboard/layout.tsx
  • server-side protected procedures in src/server/api/trpc.ts

The tRPC layer exposes:

  • publicProcedure
  • protectedProcedure
  • adminProcedure

This layered model keeps access control close to the correct boundary instead of mixing permissions directly into page rendering code.

Custom auth flows

Custom flows live outside the base provider config and are implemented through the server API and services layer.

Current examples:

  • sign up
  • forgot password / recovery

The password recovery logic (code generation, expiration, throttling) lives directly in the customAuth.ts router procedures.

Separation that scales

Keep provider wiring in auth config, route UI in src/app/[locale]/auth, reusable auth UI in src/features/auth/, and API orchestration in the tRPC router.

Extension guidance

When adding auth functionality:

  • keep provider wiring in src/server/auth/config.ts
  • keep route/form concerns inside src/app/[locale]/auth
  • keep reusable auth UI in src/features/auth/
  • keep API-facing orchestration (including recovery logic) in the relevant tRPC router

That structure makes authentication easier to understand now and safer to extend later.