Authentication & User Sessions

Relevant source files

The following files were used as context for generating this wiki page:

• src/middleware.ts
• src/app/auth/actions.ts
• src/app/auth/callback/route.ts
• src/hooks/use-session.ts
• supabase/config.toml
• e2e/auth-guard.spec.ts
• src/components/auth/auth-status.tsx
• src/lib/supabase/database.types.ts

The mdeai platform utilizes a multi-layered authentication system built on Supabase Auth, providing passwordless entry via Email Magic Links and Google OAuth. The system ensures secure access to protected resources like trip itineraries, saved collections, and host management tools while maintaining public access for general discovery features.

User sessions are managed through Supabase's server-side rendering (SSR) package, leveraging cookies for persistence and a middleware layer for route-level protection. This architecture supports high-level security requirements including Row Level Security (RLS) in the database and deterministic auth-guard journeys in the frontend.

Authentication Architecture

The architecture relies on Supabase as the identity provider. The system is configured to handle local development via a specific config.toml and production environments through environment variables.

Key Authentication Components

Component	Description
Supabase Auth	Core identity provider handling JWTs, user profiles, and auth providers.
Next.js Middleware	Intercepts requests to enforce authentication on specific paths.
Server Actions	Processes sign-in requests for Magic Links and Google OAuth.
Auth Callback	Handles the exchange of codes/tokens from external providers for active sessions.

Sources: supabase/config.toml:132-155, src/app/auth/actions.ts:13-35, README.md:17-25

Auth Flow: Magic Link & OAuth

The following diagram illustrates the sequence for authenticating a user via a Magic Link or Google OAuth, involving the redirection to an internal callback route.

Route Protection & Middleware

The application enforces a "protected-by-default" strategy for sensitive user data routes. The middleware logic evaluates every incoming request against a list of protected paths.

Protected Paths

The middleware specifically guards the following areas:

• /trips
• /saved
• /host/event/new
• /me/tickets (Exact match; subpaths like /me/tickets/[id] remain public for guest QR views).

Sources: e2e/auth-guard.spec.ts:10-25, src/middleware.ts

Middleware Logic Flow

If an unauthenticated user attempts to access a protected route, the middleware redirects them to /login, appending the original destination as a next query parameter to ensure a seamless return after authentication.

User Session Management

Sessions are handled using the @supabase/ssr package. On the client side, the useSession hook provides a reactive interface for the current user's state.

Session Data Structure

Sessions contain JWTs that are valid for 3600 seconds (1 hour) by default, with refresh token rotation enabled to maintain security.

Field	Type	Description
user	User	The authenticated user object including email and metadata.
loading	boolean	State indicating if the session is still being fetched/hydrated.
role	Enum	User permissions: user, moderator, admin, or super_admin.

Sources: src/hooks/use-session.ts, supabase/config.toml:143-146, src/lib/supabase/database.types.ts:1437-1442

Session Monitoring in UI

The AuthStatus component monitors hydration and session state to display appropriate navigation links.

// src/components/auth/auth-status.tsx
export function AuthStatus() {
  const { user, loading } = useSession();

  if (loading) return <p>Checking session…</p>;
  if (!user) {
    return (
      <>
        <Link href="/login">Sign in</Link>
        <Link href="/signup">Sign up</Link>
      </>
    );
  }
  return <div>{user.email} <SignOutButton /></div>;
}

Sources: src/components/auth/auth-status.tsx:10-35

Database & RLS Integration

Authentication is tightly coupled with the database through Row Level Security (RLS). User IDs from the auth.users table are used as foreign keys in various application tables to restrict data access.

User Profiles Schema

The profiles table stores extended user information linked to the authentication ID.

Column	Type	Description
id	uuid	Primary key linked to auth.users.id.
role	user_role	Permission level for the user.
email	text	User's primary email address.
onboarding_completed	boolean	Flag for user onboarding status.

Sources: src/lib/supabase/database.types.ts:1146-1165

Data Relationships

User IDs act as the primary owner for several entities:

• Trips: trips.user_id src/lib/supabase/database.types.ts:1400
• Collections: collections.user_id src/lib/supabase/database.types.ts:400
• Landlord Profiles: landlord_profiles.user_id src/lib/supabase/database.types.ts:680

Conclusion

Authentication and user session management in mdeapp provides a robust foundation for an AI-first concierge service. By combining Supabase's identity management with Next.js Middleware and SSR capabilities, the platform ensures that user itineraries and private collections remain secure while offering a friction-free passwordless onboarding experience. The integration of deterministic auth-guards in E2E testing ensures these security boundaries remain intact during rapid development.