Zum Inhalt

API-Keys

API-Keys sind die primäre Authentifizierungsmethode für den MoE-Orchestrator. Jeder User kann mehrere Keys erstellen, z.B. einen pro Gerät oder Anwendung.

Key-Format

moe-sk-{48 zufällige Hex-Zeichen}

Beispiel: moe-sk-a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6

Sicherheit

Der vollständige Key wird nur einmalig nach der Erstellung angezeigt. Danach ist nur noch der Prefix sichtbar. Der Key wird niemals im Klartext gespeichert — nur ein SHA-256-Hash.

Keys verwalten (/user/keys)

Meine API-Keys – Tabelle

Spalte Beschreibung
Key-Prefix Erste 16 Zeichen + ...
Label Benutzerdefinierter Name
Erstellt Erstellungsdatum
Zuletzt genutzt Letzter Nutzungszeitpunkt (nie wenn noch ungenutzt)
Status Aktiv (grün) oder Gesperrt (rot)
✎ Label bearbeiten
🔒 Key sperren

Neuen Key erstellen

  1. Bezeichnung eingeben (optional, max. 100 Zeichen, z.B. „Claude Code Laptop")
  2. Key erstellen klicken → POST /user/keys
  3. Vollständigen Key einmalig anzeigen — in die Zwischenablage kopieren!
  4. Der Key erscheint ab sofort in der Tabelle mit dem Prefix

Key-Label bearbeiten

  1. ✎-Symbol klicken → Modal öffnet sich
  2. Neues Label eingeben
  3. Speichern → PATCH /user/keys/{key_id}/label

Key sperren

  1. 🔒-Symbol klicken → Bestätigung
  2. POST /user/keys/{key_id}/revoke
  3. Key ist sofort ungültig; Redis-Cache wird invalidiert

Empfehlung

Einen Key pro Gerät/Anwendung erstellen. So kann ein kompromittierter Key gezielt gesperrt werden ohne andere Integrationen zu unterbrechen.

API-Key in Anwendungen verwenden

Der MoE-Orchestrator akzeptiert zwei Header-Formate:

curl https://moe-intern/v1/chat/completions \
  -H "Authorization: Bearer moe-sk-..." \
  -H "Content-Type: application/json" \
  -d '{"model": "qwen2.5:32b", "messages": [{"role": "user", "content": "Hallo"}]}'

curl https://moe-intern/v1/messages \
  -H "x-api-key: moe-sk-..." \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"model": "claude-sonnet-4-6", "messages": [{"role": "user", "content": "Hallo"}], "max_tokens": 1024}'

{
  "env": {
    "ANTHROPIC_BASE_URL": "http://localhost:8002/v1",
    "ANTHROPIC_API_KEY": "moe-sk-..."
  }
}

{
  "models": [{
    "title": "MoE Local",
    "provider": "openai",
    "model": "qwen2.5:32b",
    "apiBase": "http://localhost:8002/v1",
    "apiKey": "moe-sk-..."
  }]
}

Technischer Hintergrund

Validierungs-Flow

API-Request mit Header "Authorization: Bearer moe-sk-..."
        │
SHA-256-Hash des Keys berechnen
        │
Redis-Lookup: user:apikey:{hash}  →  TTL 5 Minuten
        │ Cache Hit                    │ Cache Miss
        │                             SQLite-Lookup
        │                             → Redis-Cache befüllen
        │
User-Objekt abrufen (is_active, role, limits, permissions)
        │
Budget prüfen → 429 wenn überschritten
        │
Request verarbeiten

Redis-Schema

user:apikey:{sha256}   →  HASH  {
    user_id: "...",
    username: "...",
    role: "user|expert|admin",
    is_active: "1",
    daily_limit: "100000",
    monthly_limit: "1000000",
    total_limit: "",
    permissions: "{...JSON...}"
}
TTL: 300 Sekunden (5 Minuten)

Nach einer Sperrung oder Permissions-Änderung wird der Cache sofort invalidiert → nächste Anfrage wird direkt abgewiesen bzw. mit aktuellen Rechten ausgeführt.

Datenbankschema

CREATE TABLE api_keys (
    id          TEXT PRIMARY KEY,           -- UUID4
    user_id     TEXT NOT NULL REFERENCES users(id),
    key_hash    TEXT UNIQUE NOT NULL,       -- SHA-256
    key_prefix  TEXT NOT NULL,             -- Erste 16 Zeichen
    label       TEXT,
    is_active   INTEGER DEFAULT 1,
    created_at  TEXT NOT NULL,
    last_used_at TEXT,                     -- NULL = noch nie genutzt
    expires_at  TEXT                       -- NULL = kein Ablauf
);

CREATE INDEX idx_keys_hash    ON api_keys(key_hash);
CREATE INDEX idx_keys_user    ON api_keys(user_id);