API keys

[kaseywright]

Replace the demo user authentication with API key system for internal service access and resource protection. User-based auth is not required for this internal service.

Tasks

1. API Key Model & Database

• Create ApiKey model with fields: key_hash, name, permissions, is_active, created_at, expires_at - (this might need a discussion about expiration policy)
• Add API key generation utilities using fastapi.security module
• Store only hashed keys in database (never plaintext)
• Create database functions for API key CRUD operations

2. Authentication Middleware

• Create API key authentication middleware
• Extract API key from X-API-Key header or api_key query parameter - prefer header
• Validate key hash against database
• Check key is active and not expired
• Add <limiting id> to request state for downstream use
• Scope queries to <limiting id>

3. Management Endpoints

These endpoints are not formalized yet. The list below should serve as a basis for planning endpoints.

• POST /admin/api-keys - Generate new API key
• GET /admin/api-keys - List API keys (admin only)
• PUT /admin/api-keys/{id} - Update API key
• DELETE /admin/api-keys/{id} - Revoke API key
• GET /api-keys/me - Current key info (for key holders)

4. Router Updates

• Remove user authentication from all endpoints
• Add API key requirement to protected endpoints
• Update admin routes to use API key + admin permission
• Remove user-related models and routes entirely

5. Configuration & Migration

• Add API key settings to config (key length, expiration defaults, etc.)
• Create database migration for API keys table
• Seed initial admin API key for system use

Acceptance Criteria

• All endpoints require valid API key (except health/root)
• API keys are stored as hashes only
• Permission system controls access to different endpoints
• Admin endpoints for key management work correctly
• No user authentication remains in codebase

Security Requirements

• API keys use cryptographically secure generation
• Admin endpoints require admin permission
• Keys have optional expiration dates

Dependencies

• Database connection implementation (separate ticket)
• Error handling improvements (separate ticket)
• Logging for authentication events (separate ticket)

Notes

• Consider key rotation capability (separate ticket)
• Consider key usage analytics (separate ticket)
• Rate limiting will be implemented in a separate ticket

Unknowns

• should associate API key with org? - Given that the User will the primary tenant object for Fluent, we should definitely associate keys to users. However, we will also need the functionality to associate keys to an org as well. This can be done by Polymorphic Association with a Nullable-Constrained Check
• Standardize API key request format - todo. Needs discussion.

[LijuJacob08]

DEV:

Phase	Hours (ET)
Research	4
Design	4
DB & Model	3
Middleware	3
Endpoints	4
Router Refactor	3
Config	4
Testing	3
Total	28