Authentication

Authentication is one of the most important systems in SaaSStinger Lite.

It protects your application, identifies users, secures server-side operations, and forms the foundation for workspaces, permissions, and collaboration.

Unlike many Firebase starter kits that rely entirely on client-side authentication, SaaSStinger Lite combines Firebase Authentication with server-side verification and layered authorization to provide a production-ready authentication architecture.

What You'll Learn

In this guide you'll learn:

• Supported authentication providers
• The complete authentication lifecycle
• How sessions are managed
• Why server-side verification is required
• How protected routes work
• How workspace authorization is enforced
• How to safely extend authentication

Authentication Overview

SaaSStinger Lite uses Firebase Authentication as the identity provider.

Supported sign-in methods include:

• Email & Password
• Google
• GitHub

Additional functionality includes:

• Email verification
• Password reset
• Secure logout
• Automatic onboarding
• Session persistence
• Server-side authentication

Authentication Flow

A successful login follows this sequence.

User
   │
   ▼
Firebase Authentication
   │
   ▼
ID Token Issued
   │
   ▼
HTTP-only Session Cookie
   │
   ▼
Protected Route
   │
   ▼
Workspace Gate
   │
   ▼
Role Guard
   │
   ▼
Server Action
   │
   ▼
Firebase Admin SDK
   │
   ▼
Cloud Firestore

Each layer performs a specific responsibility, creating multiple independent security boundaries.

Supported Providers

Email & Password

Email/password authentication is enabled by default.

Users can:

• Register
• Sign in
• Verify their email
• Reset forgotten passwords
• Change their password

Google

Google Sign-In is enabled by default.

On the first successful sign-in:

• the user profile is created automatically (if needed)
• onboarding starts if the user does not already belong to a workspace

GitHub

GitHub authentication follows the same onboarding flow.

If the user is new:

• a profile is created automatically (if needed)
• onboarding begins when no workspace exists

Email Verification

Email verification is required before a user can access the application.

If an unverified user signs in, SaaSStinger Lite redirects them to:

/auth/verify-email

Only after verifying their email can they continue with onboarding or access the dashboard.

This reduces the likelihood of fake accounts and ensures ownership of the registered email address.

Session Management

SaaSStinger Lite uses Firebase Authentication together with HTTP-only session cookies.

This provides a better security model than relying solely on client-side authentication state.

The overall process is:

User Signs In
        │
        ▼
Firebase Issues ID Token
        │
        ▼
Server Creates HTTP-only Session Cookie
        │
        ▼
Subsequent Requests Are Authenticated

Because the session cookie is HTTP-only, it cannot be accessed by client-side JavaScript, reducing exposure to common client-side attacks.

Architecture Note

Firebase Authentication identifies the user, while the session cookie allows trusted server-side code to authenticate requests without exposing session credentials to browser JavaScript.

Protected Routes

Every authenticated area of the application is protected before sensitive content is rendered.

SaaSStinger Lite uses multiple authorization layers rather than a single authentication check.

These include:

• ProtectedRoute
• WorkspaceGate
• RoleGuard

Each layer focuses on one responsibility.

ProtectedRoute

ProtectedRoute ensures that a user is authenticated before accessing protected pages.

If authentication fails, the user is redirected to the appropriate authentication screen.

WorkspaceGate

Being authenticated does not automatically grant access to workspace data.

WorkspaceGate verifies that:

• the user belongs to a workspace
• an active workspace exists
• the workspace context is valid

If no workspace exists, the onboarding flow begins automatically.

RoleGuard

Role-based authorization is handled separately.

RoleGuard ensures the current user has permission to perform the requested action.

Typical examples include:

• editing workspace settings
• inviting members
• managing users
• administrative operations

Separating role checks from authentication keeps the authorization model flexible and easier to maintain.

Server-Side Authentication

Every Server Action verifies the authenticated user before performing privileged operations.

Instead of trusting information supplied by the browser, SaaSStinger Lite verifies the request using the Firebase Admin SDK.

This protects sensitive operations even if a malicious client attempts to bypass the user interface.

Firestore Security

Authentication alone does not protect your database.

Firestore Security Rules remain the final authorization layer.

Even if an invalid request reaches Firestore, the database evaluates its security rules before allowing access.

This creates defense in depth:

Browser
    │
Protected Route
    │
Workspace Gate
    │
Role Guard
    │
Server Action
    │
Firebase Admin SDK
    │
Firestore Security Rules

Each layer reinforces the next.

Automatic Onboarding

When a user signs in for the first time:

1. A user profile is created if one does not already exist.
2. The application checks for an existing workspace membership.
3. If no workspace exists, onboarding begins automatically.
4. The user creates their first workspace.
5. An OWNER membership is created.
6. Usage tracking is initialized.
7. The user is redirected to the dashboard.

This ensures every authenticated user enters the application with a valid workspace context.

Secure Logout

Signing out performs several operations:

• Clears the Firebase authentication state.
• Removes the HTTP-only session cookie.
• Ends the current session.
• Redirects the user to /auth/login.

This ensures both client-side and server-side authentication state are removed.

Extending Authentication

When adding new authenticated features:

• Protect pages with ProtectedRoute.
• Verify workspace access using WorkspaceGate.
• Apply RoleGuard where authorization is required.
• Keep business logic inside services.
• Perform privileged work through Server Actions.
• Never trust client-provided user identifiers.
• Always verify the authenticated user server-side.

Following this pattern keeps new features consistent with the rest of the application.

Common Mistakes

Relying Only on Client Authentication

Client authentication identifies the user but should not be the only security boundary.

Always perform server-side verification for privileged operations.

Skipping Role Checks

Authentication does not imply authorization.

Users should only perform actions permitted by their assigned workspace role.

Exposing Sensitive Logic

Business rules and privileged operations should never rely solely on browser code.

Move sensitive logic into Server Actions and server-side services.

Ignoring Firestore Security Rules

Even when requests originate from trusted code, Firestore Security Rules should remain enabled and up to date.

Related Articles

• User Profiles
• Workspaces
• Members
• Invitations
• RBAC & Permissions
• Firestore Security Rules

Next Steps

Now that you understand how users authenticate and how requests are secured, continue with User Profiles to learn how SaaSStinger Lite stores user information and manages identities across multiple workspaces.