Documentación

Auth and Access Control

SecurityAccess boundariesRoute and API protection

Fast Unicorn protects access at both the route layer and the API layer.

The goal is to keep authentication, authorization, and ownership checks close to the boundary where each one matters most instead of mixing every rule into one place.

Related docs

For the feature overview, see Authentication. For implementation details, continue with Configure Auth or Add a Protected Page.

What this security area covers

Route protection

Protected layouts stop unauthenticated users before private UI and data are rendered.

Procedure protection

The API layer applies public, authenticated, and admin-only access boundaries through reusable procedure types.

Role and ownership checks

Authorization decisions can continue deeper into services when a route or procedure-level check is not enough.

Protection model

Route-level protection

The dashboard layout checks the session before rendering protected pages.

If no session is present, the user is redirected to the localized sign-in route.

That keeps unauthorized users from reaching private application surfaces through the route tree.

API-level protection

The tRPC layer defines three access levels in src/server/api/trpc.ts:

  • publicProcedure
  • protectedProcedure
  • adminProcedure

These shared procedure types make it easier to apply access rules consistently instead of rewriting the same checks in every mutation or query.

Session data used for authorization

The auth layer injects:

  • user.id
  • user.role

This makes it possible to protect both authenticated-only flows and admin-only flows.

Current role model

adminProcedure loads the current user from the database and verifies the stored role before allowing the request to proceed.

This ensures admin-only access depends on persisted user state rather than trusting only client-visible session shape.

Security layering

Authentication confirms who the user is. Authorization decides what they can do. Ownership rules inside services decide whether a specific resource really belongs to them.

Best practice

Protect access close to the boundary where it matters:

  • route access in layouts
  • API access in procedures
  • ownership and domain rules in services

That separation keeps the access model easier to reason about and much safer to extend later.