Forem: Tortoise

How to Add Authentication to a SvelteKit SPA

Tortoise — Mon, 27 Apr 2026 13:50:32 +0000

Originally published at turtledev.io

Building on our previous tutorial where we created a SvelteKit SPA with a FastAPI backend, let's add authentication to our application.

Building a production app? Check out FastSvelte — a production-ready FastAPI + SvelteKit starter with authentication, payments, and more built-in.

This tutorial demonstrates a minimal authentication implementation for learning purposes, covering:

HTTP-only cookie-based sessions
Reactive auth state management with Svelte 5 runes
Protected routes with automatic redirects
Optimized auth checks with caching

Note: This is a tutorial project for learning concepts. For production applications, use solutions like FastSvelte, Auth.js, Lucia, or your backend framework's authentication library.

Prerequisites

Completed the SvelteKit SPA with FastAPI tutorial or have a similar setup
Basic understanding of SvelteKit and FastAPI
Familiarity with Svelte 5 runes ($state, $effect)

Authentication Flow

Our authentication system uses HTTP-only cookies for secure session management. Here's how the complete flow works:

┌─────────────────────────────────────────────────────────────────────┐
│                          LOGIN FLOW                                 │
└─────────────────────────────────────────────────────────────────────┘

Browser                    SvelteKit Frontend              FastAPI Backend
   │                              │                              │
   │  1. Enter credentials        │                              │
   │  ──────────────────────────> │                              │
   │                              │                              │
   │                              │  2. POST /auth/login         │
   │                              │  {email, password}           │
   │                              │  ──────────────────────────> │
   │                              │                              │
   │                              │                              │  3. Validate
   │                              │                              │     credentials
   │                              │                              │
   │                              │  4. Set-Cookie: session=xxx  │
   │                              │     (HTTP-only, SameSite)    │
   │                              │  <────────────────────────── │
   │                              │                              │
   │  5. Cookie stored            │                              │
   │  <────────────────────────── │                              │
   │     (inaccessible to JS)     │                              │
   │                              │                              │
   │  6. Redirect to /welcome     │                              │
   │  <────────────────────────── │                              │
   │                              │                              │

Step-by-step breakdown:

User enters their email and password in the login form
Frontend sends credentials to the backend's /auth/login endpoint
Backend validates the credentials against the user database (in-memory for this tutorial)
Backend creates a session token and sends it back as an HTTP-only cookie
Browser automatically stores the cookie (JavaScript cannot access it due to httponly flag)
Frontend redirects the user to the dashboard/welcome page

┌─────────────────────────────────────────────────────────────────────┐
│                     AUTHENTICATED REQUEST                           │
└─────────────────────────────────────────────────────────────────────┘

Browser                    SvelteKit Frontend              FastAPI Backend
   │                              │                              │
   │  1. Navigate to /todos       │                              │
   │  ──────────────────────────> │                              │
   │                              │                              │
   │                              │  2. GET /users/me            │
   │                              │     Cookie: session=xxx      │
   │                              │  ──────────────────────────> │
   │                              │                              │
   │                              │                              │  3. Validate
   │                              │                              │     session
   │                              │                              │
   │                              │  4. {id, email, ...}         │
   │                              │  <────────────────────────── │
   │                              │                              │
   │  5. Update auth store        │                              │
   │  <────────────────────────── │                              │
   │                              │                              │
   │  6. GET /todos               │                              │
   │     Cookie: session=xxx      │                              │
   │  ─────────────────────────────────────────────────────────> │
   │                              │                              │
   │                              │                              │  7. Validate
   │                              │                              │     session
   │                              │                              │
   │  8. Todo list data           │                              │
   │  <───────────────────────────────────────────────────────── │
   │                              │                              │

Key Security Features

HTTP-only Cookies: Session tokens stored in HTTP-only cookies are completely inaccessible to JavaScript. First line of defense against XSS attacks.

SameSite Protection: SameSite=Lax during development. In production use SameSite=Strict for CSRF protection.

Credentials Configuration: Axios needs withCredentials: true to send cookies with cross-origin requests.

Session Validation on Every Request: Every protected endpoint validates the session cookie. Frontend auth state is only for UX — real security happens on the backend.

Backend Implementation

Quick note: This backend is intentionally minimal. We're using in-memory storage, plain-text passwords, and other shortcuts you'd never use in production. The focus is the frontend auth implementation.

Our backend does three key things:

1. Creates sessions when users log in

@app.post("/auth/login")
def login(request: LoginRequest, response: Response):
    user_data = MOCK_USERS.get(request.email)

    if not user_data or user_data["password"] != request.password:
        raise HTTPException(status_code=401, detail="Invalid credentials")

    token = create_session(user_data["id"])
    set_session_cookie(response, token)
    return LoginSuccess(user_id=user_data["id"], email=request.email)

def create_session(user_id: int) -> str:
    token = secrets.token_urlsafe(32)
    sessions[token] = user_id
    return token

secrets.token_urlsafe(32) generates a cryptographically secure token. Never use random or uuid for session tokens.

def set_session_cookie(response: Response, token: str):
    response.set_cookie(
        key="session",
        value=token,
        httponly=True,
        secure=False,  # Set to True in production with HTTPS
        samesite="lax",
        max_age=3600,
        path="/"
    )

2. Validates sessions on protected endpoints

@app.get("/todos")
def list_todos(user: User = Depends(get_current_user)):
    return list(todos.values())

def get_current_user(request: Request) -> User:
    token = request.cookies.get("session")

    if not token or token not in sessions:
        raise HTTPException(status_code=401, detail="Not authenticated")

    user_id = sessions[token]
    # Look up user from database and return User object
    # ...

3. Clears sessions on logout

@app.post("/auth/logout", status_code=204)
def logout(request: Request, response: Response, user: User = Depends(get_current_user)):
    token = get_session_token(request)
    if token:
        invalidate_session(token)
    clear_session_cookie(response)

CORS configuration:

app.add_middleware(
    CORSMiddleware,
    allow_origins=["http://localhost:5173"],
    allow_credentials=True,  # Critical: allows cookies
    allow_methods=["*"],
    allow_headers=["*"],
)

allow_credentials=True is essential. Without it, the browser won't send or receive cookies in cross-origin requests.

Frontend Implementation

Step 1: Configure Axios to Send Cookies

// lib/api/axios-config.ts
import axios from 'axios';

axios.defaults.withCredentials = true;

Import this in +layout.ts so it runs before anything else:

// routes/+layout.ts
import '$lib/api/axios-config';

export const csr = true;
export const ssr = false;
export const prerender = false;

Step 2: Build a Reactive Auth Store

// lib/auth/auth.svelte.ts
import type { User } from '$lib/api/gen/model';

class AuthStore {
    user = $state<User | null>(null);
    isLoading = $state(true);

    get isAuthenticated(): boolean {
        return this.user !== null;
    }

    setUser(user: User | null) {
        this.user = user;
        this.isLoading = false;
    }

    clear() {
        this.user = null;
        this.isLoading = false;
    }
}

export const authStore = new AuthStore();

The $state rune makes user and isLoading reactive. Any component that reads them automatically updates when they change. No subscriptions, no boilerplate.

Step 3: Session Validation with Smart Caching

// lib/auth/session.ts
const api = getFastAPI();

let lastSuccessfulCheck = 0;
const AUTH_CHECK_EXPIRES_MS = 20000; // 20 seconds

export async function ensureAuthenticated(): Promise<boolean> {
    const now = Date.now();

    if (authStore.isAuthenticated && now - lastSuccessfulCheck < AUTH_CHECK_EXPIRES_MS) {
        return true;
    }

    if (!authStore.isAuthenticated) {
        authStore.setLoading(true);
    }

    try {
        const response = await api.getCurrentUser();
        authStore.setUser(response.data);
        lastSuccessfulCheck = now;
        return true;
    } catch (error) {
        authStore.clear();
        window.location.href = '/login';
        return false;
    }
}

About the 20-second cache: This is a performance optimization to avoid hammering /users/me, not your session expiry. Your actual session might last 30-60 minutes on the backend. The backend still validates the session on every API call.

Step 4: Protect Routes with a Layout

<!-- routes/(protected)/+layout.svelte -->
<script lang="ts">
    import { onMount } from 'svelte';
    import { ensureAuthenticated } from '$lib/auth/session';
    import { authStore } from '$lib/auth/auth.svelte';

    let { children } = $props();

    onMount(async () => {
        await ensureAuthenticated();
    });
</script>

{#if authStore.isLoading}
    <div class="loading">Loading...</div>
{:else if authStore.isAuthenticated}
    {@render children()}
{:else}
    <div class="loading">Redirecting to login...</div>
{/if}

Any route inside the (protected) folder automatically requires authentication:

routes/
  (protected)/
    +layout.svelte      ← Auth check happens here
    todos/
      +page.svelte      ← Automatically protected
    profile/
      +page.svelte      ← Automatically protected
  login/
    +page.svelte        ← Public route

Step 5: Logout

export async function logout(): Promise<void> {
    try {
        await api.logout();
    } catch (error) {
        console.error('Logout failed:', error);
    } finally {
        authStore.clear();
        lastSuccessfulCheck = 0;
        goto('/login');
    }
}

Even if the API call fails, local state clears and the user gets redirected. They can't stay on a protected page without re-authenticating.

Wrapping Up

You now have a working authentication system for your SvelteKit SPA:

HTTP-only cookie-based sessions
Reactive auth store with Svelte 5 runes
Smart caching to reduce backend calls
Protected routes via layouts
Clean login and logout flows

Source code: GitHub

This covers the fundamentals. Production apps need password reset, email verification, OAuth, and RBAC. If you want all of that without building it from scratch, check out FastSvelte — a SvelteKit + FastAPI starter kit with auth, Stripe billing, multi-tenancy, and more already wired up.

Smooth coding!

How to Build a SvelteKit SPA with FastAPI Backend

Tortoise — Sun, 26 Apr 2026 13:44:33 +0000

Originally published at turtledev.io

In my previous post, I talked about why I moved from SvelteKit SSR to a Svelte SPA + FastAPI architecture. Today, I want to show you my setup with a simple project.

We'll build a simple todo list app to demonstrate how the frontend and backend communicate, and how to write less and type-safe code by using Orval to auto-generate TypeScript API clients from FastAPI's OpenAPI specs.

Building a production app? Check out FastSvelte - a production-ready FastAPI + SvelteKit starter with authentication, payments, and more built-in.

Project Structure

todo-app/
├── backend/          # FastAPI Python backend
│   ├── main.py       # FastAPI app
│   ├── models.py     # Pydantic models
│   └── requirements.txt
│
└── frontend/         # SvelteKit SPA
    ├── src/
    │   ├── routes/   # Pages
    │   └── lib/      # API client & components
    └── package.json

Backend: FastAPI Setup

Create a backend directory and set up a virtual environment:

cd backend
python3 -m venv .venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate

requirements.in

We'll use pip-compile from pip-tools to manage dependencies:

Simple dependency specification: List only your direct dependencies without worrying about version pins
Clear dependency tree: The generated requirements.txt shows direct vs transitive dependencies
Reproducible builds: All versions are pinned for consistent installations
Easy updates: Run pip-compile again to update to latest compatible versions

fastapi
uvicorn[standard]
pydantic

Install pip-tools and compile dependencies

pip install pip-tools
pip-compile requirements.in
pip install -r requirements.txt

models.py

# backend/models.py
from pydantic import BaseModel

class TodoCreate(BaseModel):
    title: str
    completed: bool = False

class TodoUpdate(BaseModel):
    title: str | None = None
    completed: bool | None = None

class Todo(BaseModel):
    id: int
    title: str
    completed: bool

main.py

# backend/main.py
from fastapi import FastAPI, HTTPException
from fastapi.middleware.cors import CORSMiddleware
from models import Todo, TodoCreate, TodoUpdate

app = FastAPI()

app.add_middleware(
    CORSMiddleware,
    allow_origins=["http://localhost:5173"],  # Vite dev server
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

todos: dict[int, Todo] = {}
next_id = 1

@app.get("/todos", response_model=list[Todo], operation_id="listTodos")
def list_todos():
    """Get all todos"""
    return list(todos.values())

@app.post("/todos", response_model=Todo, operation_id="createTodo")
def create_todo(todo_data: TodoCreate):
    """Create a new todo"""
    global next_id
    todo = Todo(id=next_id, title=todo_data.title, completed=todo_data.completed)
    todos[next_id] = todo
    next_id += 1
    return todo

@app.get("/todos/{todo_id}", response_model=Todo, operation_id="getTodo")
def get_todo(todo_id: int):
    """Get a specific todo"""
    if todo_id not in todos:
        raise HTTPException(status_code=404, detail="Todo not found")
    return todos[todo_id]

@app.put("/todos/{todo_id}", response_model=Todo, operation_id="updateTodo")
def update_todo(todo_id: int, todo_data: TodoUpdate):
    """Update a todo"""
    if todo_id not in todos:
        raise HTTPException(status_code=404, detail="Todo not found")
    todo = todos[todo_id]
    if todo_data.title is not None:
        todo.title = todo_data.title
    if todo_data.completed is not None:
        todo.completed = todo_data.completed
    return todo

@app.delete("/todos/{todo_id}", status_code=204, operation_id="deleteTodo")
def delete_todo(todo_id: int):
    """Delete a todo"""
    if todo_id not in todos:
        raise HTTPException(status_code=404, detail="Todo not found")
    del todos[todo_id]

Notice the operation_id on each route. This tells FastAPI to use clean names like listTodos in the OpenAPI spec instead of auto-generated ones like list_todos_todos_get. Orval will use these as TypeScript function names.

Start the backend

uvicorn main:app --reload

API running at http://localhost:8000. Docs at http://localhost:8000/docs.

Test the API

# Create a todo
curl -X POST http://localhost:8000/todos \
  -H "Content-Type: application/json" \
  -d '{"title": "Learn FastAPI", "completed": false}'

# List all todos
curl http://localhost:8000/todos

# Update a todo
curl -X PUT http://localhost:8000/todos/1 \
  -H "Content-Type: application/json" \
  -d '{"completed": true}'

# Delete a todo
curl -X DELETE http://localhost:8000/todos/1

The OpenAPI spec is at http://localhost:8000/openapi.json — this is what Orval will use to generate the TypeScript client.

Frontend: SvelteKit SPA

npx sv create frontend

Select: SvelteKit minimal, TypeScript, prettier, npm.

Configure as SPA

Create src/routes/+layout.ts:

export const csr = true;        // Enable client-side rendering
export const ssr = false;       // Disable server-side rendering
export const prerender = false; // Disable prerendering

Install Dependencies

npm install axios
npm install -D orval

Setup Auto-Generated API Client

Create orval.config.cjs:

module.exports = {
    default: {
        input: {
            target: 'http://localhost:8000/openapi.json'
        },
        output: {
            target: './src/lib/api/gen',
            schemas: './src/lib/api/gen/model',
            client: 'axios',
            mode: 'split',
            clean: true,
            baseUrl: 'http://localhost:8000'
        }
    }
};

Add a generate script to package.json:

{
    "scripts": {
        "generate": "npx orval --config orval.config.cjs"
    }
}

Generate TypeScript Client

With your backend running:

npm run generate

This creates src/lib/api/gen/ with fully typed functions for all your endpoints.

Build the UI

Create src/routes/+page.svelte:

<script lang="ts">
    import { onMount } from 'svelte';
    import { getFastAPI } from '$lib/api/gen/fastAPI';
    import type { Todo } from '$lib/api/gen/model';

    const api = getFastAPI();

    let todos = $state<Todo[]>([]);
    let newTodoTitle = $state('');
    let loading = $state(false);

    async function loadTodos() {
        loading = true;
        try {
            const response = await api.listTodos();
            todos = response.data;
        } catch (error) {
            console.error('Failed to load todos:', error);
        } finally {
            loading = false;
        }
    }

    async function addTodo() {
        if (!newTodoTitle.trim()) return;
        try {
            const response = await api.createTodo({ title: newTodoTitle, completed: false });
            todos = [...todos, response.data];
            newTodoTitle = '';
        } catch (error) {
            console.error('Failed to create todo:', error);
        }
    }

    async function toggleTodo(todo: Todo) {
        try {
            const response = await api.updateTodo(todo.id, { completed: !todo.completed });
            todos = todos.map((t) => t.id === todo.id ? response.data : t);
        } catch (error) {
            console.error('Failed to update todo:', error);
        }
    }

    async function removeTodo(id: number) {
        try {
            await api.deleteTodo(id);
            todos = todos.filter((t) => t.id !== id);
        } catch (error) {
            console.error('Failed to delete todo:', error);
        }
    }

    onMount(() => { loadTodos(); });
</script>

<div class="container">
    <h1>Todo List</h1>

    <div class="add-todo">
        <input
            type="text"
            bind:value={newTodoTitle}
            placeholder="What needs to be done?"
            onkeydown={(e) => e.key === 'Enter' && addTodo()}
        />
        <button onclick={addTodo}>Add</button>
    </div>

    {#if loading}
        <p>Loading...</p>
    {:else if todos.length === 0}
        <p class="empty">No todos yet. Add one above!</p>
    {:else}
        <ul class="todo-list">
            {#each todos as todo (todo.id)}
                <li class:completed={todo.completed}>
                    <input type="checkbox" checked={todo.completed} onchange={() => toggleTodo(todo)} />
                    <span>{todo.title}</span>
                    <button class="delete" onclick={() => removeTodo(todo.id)}>×</button>
                </li>
            {/each}
        </ul>
    {/if}
</div>

Start the frontend

npm run dev

App running at http://localhost:5173.

Updating the API

When you add a field to a model:

class TodoCreate(BaseModel):
    title: str
    completed: bool = False
    priority: str = "medium"  # New field!

Just regenerate:

npm run generate

TypeScript will immediately show errors wherever you need to update the frontend. No manual type syncing.

What We Built

FastAPI backend with CRUD endpoints
SvelteKit SPA frontend
Auto-generated TypeScript API client from OpenAPI spec
Fully functional todo app with end-to-end type safety

Source code: GitHub

Next: How to Add Authentication to a SvelteKit SPA

If you want a production-ready version with authentication, multi-tenancy, and Stripe already wired up, check out FastSvelte.

Smooth coding!

Why I Switched from SvelteKit SSR to SPA + FastAPI

Tortoise — Sat, 25 Apr 2026 13:16:30 +0000

Originally published at turtledev.io

Hi, I'm Harun, a software engineer who's been building SaaS products for the past few years.

I come from a backend background. To get into frontend development, I tried several frameworks (Angular, Vue, and React) but Svelte was the only framework I could understand just by looking at examples. It clicked immediately. Since then I've been using Svelte for everything including this static blog.

SvelteKit is the natural next step: routing, SSR, full-stack features out of the box. But its default model is SSR, and there's a lot less content out there on using it as a pure SPA. So I went with SSR, same as everyone in the React world goes with Next.js.

Most of my projects also needed AI and ML, which meant a Python backend. So I ended up with two backends: one for SSR, one for the actual logic, both hitting the same database and talking to each other. That got messy fast.

The dev experience wasn't great either:

Pages were slow, especially on Vercel. Cold starts on serverless functions didn't help.
Every request that touched Python had an extra hop through the SSR layer.
Backend logic kept bleeding into the frontend where it didn't belong.

Honestly, I don't remember the exact moment it clicked. At some point I just got tired of the two-backend setup and started looking for a way out. Being a backend developer at heart probably played a role. The idea of owning a clean API and treating the frontend as a thin presentation layer grew in my mind, and eventually I gave it a try.

After Switching to SPA + FastAPI

Once I switched, the improvement was immediate.

Pages loaded instantly, navigation was smooth, no more cold start delays. More importantly, the architecture finally made sense. The backend did the heavy lifting, the frontend just consumed the API and rendered. DB writes, OAuth, AI calls, Stripe integration, all in the backend where they belonged.

The other big win was independent deploys. Frontend and backend shipped on their own schedules. Hotfix a UI bug? Redeploy the SPA without touching the backend. Update the schema? The frontend didn't care until you told it to.

You do need two pipelines instead of one, but with GitHub Actions it takes maybe 30 minutes to set up, and AI tools are pretty good at generating the YAML anyway.

Building a production app? Check out FastSvelte - a production-ready FastAPI + SvelteKit starter with authentication, payments, and more built-in.

When SEO Doesn't Matter

One of the main selling points of SSR is SEO. But for a SaaS dashboard, SEO doesn't really matter.

Your authenticated app isn't being crawled by Google anyway. SEO matters for your marketing site, landing pages, and blog posts, not your user dashboard.

And for those, a separate SvelteKit app with static generation gives you way more flexibility and blazing speed. In one of the AI startups I worked at, the landing page was built with WordPress and no one from the dev team was responsible for it — it was the marketing team's job. I highly recommend separating your marketing site from the actual SaaS app. Host the landing page on mysaas.com and the app on app.mysaas.com.

Why Vercel Pushes SSR

Vercel's business model is built around serverless rendering, not static hosting. SSR keeps apps running on their infrastructure continuously, which means more usage and more billing. It's not a bad thing. It just means SSR fits their model, not necessarily yours.

If your app doesn't need SEO and runs mostly behind login, static + API is cheaper, faster, and simpler to scale.

The Hosting Reality

Another advantage often mentioned about SSR is deploying everything to one place (Vercel, Netlify, etc.). But I needed a Python backend anyway for AI tasks, so I had to host that somewhere. The first thought was serverless functions (AWS Lambda, Azure Functions). I've had many years of experience with both. They're great for small tasks, especially jobs that run periodically or can tolerate some delay. But for a real web API, they start to show their limitations.

Cold starts: solvable by pinging your API periodically, but yet another thing to maintain.
Deployment complexity: AWS Lambda requires packaging your code and dependencies, setting up IAM roles, and configuring API Gateway. Azure Functions are easier but still require some setup.
Web frameworks: when building a web API you really feel the need for a proper framework, but most aren't designed to run in serverless environments. I've tried AWS Lambda Powertools in the past — it's nowhere near FastAPI or Flask.

So I decided to dockerize the backend and host it on Azure Container Apps. It turned out to be a perfect middle ground:

Around $10/month for a small app with 1 replica running at all times. Much cheaper if you set min replicas to 0, but that brings cold starts back. For production, I recommend at least 1.
Auto-scales when traffic grows.
The free tier is generous: 180,000 vCPU-seconds, 360,000 GiB-seconds, and 2 million requests/month. More than enough for an early-stage SaaS.

Since I was already on Azure, I tried Azure Static Web Apps for the SPA frontend. Fast, simple, and free: 100 GB bandwidth, 3 custom domains, seamless CI/CD with GitHub.

For the database, you can use the free Postgres instance on Vercel. Or keep your frontend + DB on Vercel and your backend on Azure. This flexibility is exactly what I love about separating concerns.

Bonus: How to Get Azure Credits

If you have a startup, you can get free Azure credits through the Microsoft for Startups Founders Hub program. Most startups are eligible for at least $5,000 in credits. I got $25,000, which covers hosting costs for the first year or two.

Bonus: Client Code Generation

With FastAPI's OpenAPI spec, you can generate API client code automatically with Orval (TypeScript) or OpenAPI Generator. Whenever you update the backend API, just regenerate the client and the frontend stays in sync. No more writing fetch wrappers manually — typed functions for every endpoint.

Building a production app? Check out FastSvelte - a production-ready FastAPI + SvelteKit starter with authentication, payments, and more built-in.

What's Next

Smooth coding!