# ADR 001: Authentication Strategy

## Status
Accepted

## Context
The application is being prepared for deployment to a public server. Currently, it has no authentication mechanism. We need to secure the application to prevent unauthorized access to personal task data (Todoist, Trello, etc.).

## Decision
We will implement **Session-Based Authentication** using server-side sessions stored in SQLite.

### Technical Details:
1.  **Session Management:** Use `alexedwards/scs` (v2) for session management.
    *   It provides a robust, secure implementation of session cookies.
    *   It supports SQLite as a backing store, simplifying infrastructure (no Redis needed).
2.  **User Storage:** Create a `users` table in the existing SQLite database.
    *   Columns: `id`, `username`, `password_hash`, `created_at`.
3.  **Password Hashing:** Use `bcrypt` (via `golang.org/x/crypto/bcrypt`) for hashing passwords.
4.  **Middleware:** Implement a middleware function to protect routes.
    *   Public routes: `/login`, `/static/*`.
    *   Protected routes: `/`, `/api/*`, etc.

## Consequences
*   **Pros:**
    *   Simple architecture (keeps everything in SQLite).
    *   Standard, well-understood security model.
    *   `scs` handles cookie security (HttpOnly, Secure, SameSite) automatically.
*   **Cons:**
    *   Stateful (sessions in DB), but acceptable for this scale.
    *   Requires managing a user table and password resets (though we will start with manual user creation).

## Alternatives Considered
*   **Basic Auth:** Too simple, poor UX (browser popup), hard to log out.
*   **OAuth (Google/GitHub):** Overkill for a single-user/small-group app initially. Adds external dependencies and configuration complexity.
*   **JWT (Stateless):** Adds complexity with token revocation and refresh tokens. Session-based is simpler for a server-rendered app.