Auth-Middleware in Bun.js: JWT, Sessions, API Keys und Multi-Tenant-Context ohne Chaos
Ein praktischer Deep Dive zu Auth-Middleware in Bun.js: wie man JWT-, Session- und API-Key-Prüfungen baut, wo Tenant Context gespeichert werden sollte, wie man 401/403 trennt, was man cachen kann, wie Token-Leaks vermieden werden und welche Best Practices von OWASP, Hono und Elysia sinnvoll sind.
Bun.js Middleware Production Guide 2026
Eine Serie über Production Middleware in Bun.js: Überblick, Security, Performance, Observability, Rate Limiting, Body Parsing, WebSocket/SSE und Tests für die Request Pipeline.
Alle Artikel in diesem Guide
01
Bun.js Middleware 2026: Overview, Best Practices und Anti-Patterns
Das grundlegende mentale Modell für Middleware in nativem Bun, Hono und Elysia, mit Beispielen, Optimierung und Roadmap für die nächsten Deep-Dive-Artikel.
02
Auth Middleware in Bun.js: JWT, Sessions, API Keys und Multi-Tenant Context
Wie man Auth Middleware in Bun richtig baut: Reihenfolge der Prüfungen, Cache, Token Rotation, Tenant Context, 401/403-Fehler und Tests.
03
Rate Limiting in Bun.js: in-memory, Redis, Sliding Window und Edge Cases
Ein detaillierter Blick auf Rate Limiting für Bun APIs: Algorithmen, Redis, distributed limits, abuse protection und graceful degradation.
04
Observability Middleware in Bun.js: Logs, Request ID, Tracing und Latency Budgets
Wie man request id, structured logs, timing headers, einen OpenTelemetry-ähnlichen Flow hinzufügt und Logging nicht zum Bottleneck macht.
05
Body Parsing und Validation in Bun.js: JSON, Uploads, Streams und Payload Limits
Wie man Request Bodies in Bun sicher liest, wo Limits hingehören und wie man Streams, Uploads, Idempotency und Schema Validation nicht kaputtmacht.
Die gefährlichsten Auth-Bugs sehen selten so aus: „Ein Nutzer ohne Token kam ins System.“ Häufiger ist der Token gültig, die Session existiert, der API Key ist echt, aber die Middleware hat den Request an den falschen Tenant gebunden, einen Scope nicht geprüft, 401 und 403 verwechselt oder ein Secret geloggt.
Bun gibt dir einen schnellen HTTP Layer, aber Auth ist kein Runtime Trick. Auth ist ein Contract: welche Credentials akzeptiert werden, wo sie gespeichert sind, wie sie validiert werden, wer User Context erstellt, wo Authorization beginnt und wie das alles getestet wird.
In diesem Artikel bauen wir nicht „noch ein Login Tutorial“. Wir zerlegen Production Patterns für Auth-Middleware in Bun APIs.
karte
Das ist das zweite Chapter der Serie über Bun Middleware. Das erste hat das allgemeine Pipeline-Modell erklärt; dieses fokussiert sich auf den Auth Layer: wo er dünn bleiben sollte, wo er Storage braucht und wo er keine Middleware mehr ist.
decode ohne Verify keine Auth ist. [4]Es gibt nicht den einen „richtigen“ Auth-Mechanismus. Es gibt unterschiedliche Trade-offs: stateless Verification, kontrollierter Logout, Machine-to-Machine Access, Rotation, Revocation und UX.
| Mechanismus | Wann geeignet | Was prüfen | Hauptrisiko |
|---|---|---|---|
| JWT access token | Mobile/API Clients, Service-to-Service, verteilte Verification | exp, iss, aud, signature, algorithm, subject, scopes | Schwieriges Revocation-Modell und die Versuchung, langlebige Tokens zu erstellen |
| Server-side session | Browser Apps, Dashboards, SaaS, wo kontrollierter Logout nötig ist | Session id in secure cookie, session store, expiry, device/risk metadata | Session Fixation, unsichere Cookies, schwaches Store Cleanup |
| API key | Integrationen, Webhooks, interne Automationen, Machine Clients | Hashed key lookup, scope, owner, environment, last used, rotation | Plaintext Key Storage und Keys ohne Scopes oder Expiry Policy |
| Hybrid | BFF, Enterprise SaaS, Admin Panels plus Public API | Session für Browser, JWT/API Keys für Services | Unterschiedliche Auth-Modelle ohne einheitliches Audit und Error Contract |
JWT, Sessions und API Keys lösen unterschiedliche Aufgaben: stateless access, Browser Logout Control und Machine-to-Machine Access.
Screenshot des Abschnitts credential-mapKurz gesagt
Für Browser SaaS startet man meistens mit Sessions. Für externe APIs passen API Keys oder kurzlebige JWT. Für verteilte Systeme: JWT plus Revocation oder Introspection dort, wo das Risiko hoch ist.
In nativem Bun.serve kannst du einen Auth Layer ohne Framework bauen. Wichtig ist, keinen globalen State zu mutieren und Context nicht in module-level Variablen zu verstecken. Gib Context explizit weiter: entweder über einen Wrapper oder über einen eigenen AppRequestContext.
Ein einfacher Pattern sieht so aus:
type AuthContext = {
subjectId: string;
tenantId: string;
scopes: string[];
method: "jwt" | "session" | "api-key";
};
type AppContext = { auth: AuthContext | null; requestId: string };
type Handler = (req: Request, ctx: AppContext) => Promise<Response> | Response;
type Middleware = (next: Handler) => Handler;
const unauthorized = () =>
Response.json({ error: "unauthorized" }, { status: 401 });
const withAuth: Middleware = (next) => async (req, ctx) => {
const header = req.headers.get("authorization");
if (!header?.startsWith("Bearer ")) return unauthorized();
const token = header.slice("Bearer ".length);
const auth = await verifyAccessToken(token);
if (!auth) return unauthorized();
return next(req, { ...ctx, auth });
};
Bun.serve({
fetch: withAuth(async (_req, ctx) => {
return Response.json({ subjectId: ctx.auth?.subjectId });
}),
});Dieses Beispiel zeigt bewusst keine Implementierung von verifyAccessToken, weil sie von deiner JWT-/Session-/API-Key-Lösung abhängt. Wichtig ist die Form: Middleware liest keine Business Resource, prüft keine Permissions auf invoice/project/order und erzeugt keine Side Effects. Sie erstellt Auth Context oder gibt 401 zurück.
Was hier wichtig ist
Context muss request-scoped und explizit sein. Wenn Auth State in einer globalen Variable, einem Singleton oder einem mutable module object lebt, entsteht ein Leakage-Risiko zwischen Requests.
Wenn du nicht den kompletten Auth Layer selbst schreiben willst, bieten Hono und Elysia fertige Primitives. Aber fertige Middleware ersetzt nicht deine Regeln für issuer, audience, scopes, tenant und error contract.
Honojwt()prüft den Token und legt den Payload überc.get('jwtPayload')in den Context; die Middleware sucht denAuthorizationHeader, wenn keine Cookie Option konfiguriert ist. [2]
HonobearerAuth()eignet sich für API Tokens und bietetverifyToken, custom errors, realm, prefix und headerName. [3]
Kurz gesagt
Built-in Middleware ist sinnvoll für Parsing und grundlegende Verification. Tenant Resolution, Scopes, Audit und Business Authorization bleiben aber Application Design.
In SaaS sieht der häufigste Auth-Fehler nicht aus wie „kein Token“, sondern wie „ein valid user konnte in einem fremden Tenant arbeiten“. Der Grund ist simpel: Die Middleware hat x-tenant-id aus dem Request genommen und nicht geprüft, ob das Subject wirklich Zugriff auf diesen Tenant hat.
Tenant Context muss aus dem Credential abgeleitet oder gegen server-side Membership geprüft werden. Wenn Nutzer Tenants wechseln können, kann ein Header oder Path Param ein Input sein, aber keine Authority.
Der richtige Flow: Credential prüfen, Subject holen, allowed tenants/scopes holen, requested tenant mit der allowed list abgleichen, resolved tenant im Context anhängen. Wenn der Tenant nicht erlaubt ist, ist das 403, nicht 401.
x-tenant-id nicht als Source of Truth.Tenant muss vom Server resolved und geprüft werden. Header oder Path Param kann die Anfrage des Nutzers sein, aber kein Beweis für Zugriff.
Screenshot des Abschnitts multi-tenant-contextFalsche Auth Errors erzeugen Probleme für Clients, Logs und Security Review. In einer Bun Pipeline sollte der Contract früh festgelegt werden.
Credential fehlt oder ist ungültig
Kein Authorization, malformed token, invalid signature, session expired, API key nicht gefunden. Der Client muss verstehen, dass Authentication nötig ist.
Credential ist gültig, aber die Aktion ist verboten
Subject ist authenticated, hat aber keinen Tenant Access, Scope, Role oder Permission für die Ressource.
Auth Abuse oder Rate Limit
Brute Force, zu viele invalid token attempts, API key abuse. Vermische das nicht mit 401, weil Client und Monitoring anders reagieren müssen.
Auth Infrastructure Failure
Session Store, JWKS Endpoint, Redis oder DB ist nicht verfügbar. Für manche Routes ist fail closed besser; für public degraded flows kann eine andere Policy nötig sein.
Kurz gesagt
Ein einheitliches Error Format ist genauso wichtig wie der richtige Status Code. Client, Monitoring und Security Tooling müssen einen stabilen Contract sehen.
Auth wird oft zur schwersten Middleware, weil Crypto, Storage, Tenant Resolution und Audit zusammenkommen. Optimierung beginnt nicht beim Algorithmus, sondern bei Routing und Caching Policy.
Gut: public/system routes außerhalb der Auth Pipeline
/health, /ready, static assets und public docs sollten kein Token Parsing oder Session Lookup machen.
Vorsicht: DB Lookup für jedes JWT
Wenn jedes JWT trotzdem zur Verification in die DB geht, frage dich, ob JWT dir gegenüber einer Session ID überhaupt einen Vorteil gibt. Vielleicht brauchst du ein Session-/Introspection-Modell.
Gut: kurzer Cache für stabile Auth Metadata
Tenant Membership, API Key Owner und JWKS Keys können mit klarer TTL und Revocation Story gecacht werden.
Vorsicht: langlebiger Permissions Cache
Permissions ändern sich. Wenn der Cache länger lebt als die Security Expectation, behält ein Nutzer nach Revoke weiterhin Zugriff.
Kurz gesagt
Auth Performance darf nicht mit Revocation kollidieren. Wenn du cachst, definiere sofort TTL, Invalidation und High-Risk Fallback.
Diese Fehler sind nicht nur Bun-spezifisch, aber in Bun-Projekten tauchen sie oft als „wir haben nur schnell eine thin middleware geschrieben“ auf.
jwt.decode() verwenden oder Payload ohne Signature Verification lesen.
exp, iss, aud und Algorithmus bei JWT nicht prüfen.
Access Token in localStorage für eine Browser App speichern, ohne klare XSS Threat Model.
Authorization, Cookies, Refresh Token oder vollständigen API Key loggen.
API Keys in Plaintext statt hash + prefix lookup speichern.
API Key ohne Scopes, Owner, Environment und Rotation Policy ausgeben.
x-tenant-id als autoritative Quelle für Tenant Context behandeln.
200 mit { error: ... } für Auth Failures zurückgeben.
Authentication, Tenant Membership und Resource Authorization in eine globale Middleware mischen.
Review-Regel
Wenn Middleware nicht als kleine State Machine mit 401/403/next erklärbar ist, ist sie schon zu komplex oder übernimmt Verantwortung für die falsche Schicht.
Vor Staging oder Security Review lohnt sich diese Liste. Sie ist bewusst als Engineering Checklist formuliert, nicht als generischer Rat.
Credential Extraction passiert einmal
Eine Schicht liest Authorization/cookies/API key und gibt das Ergebnis als typed context weiter.
JWT Verification ist vollständig
Signature, algorithm, expiry, issuer, audience, subject und clock skew policy werden geprüft.
Session Cookies sind geschützt
httpOnly, secure, sameSite, enger path, TTL und HTTPS policy sind definiert.
API Keys werden nicht offen gespeichert
In der Datenbank liegen nur hash, key prefix, owner, scopes, last used, created/revoked metadata.
Tenant Context wird geprüft
Requested tenant wird gegen membership/scopes des Subjects geprüft und nicht als Fakt aus einem Header übernommen.
401 und 403 sind getrennt
Missing/invalid credential ergibt 401; valid credential ohne permission ergibt 403.
Secrets sind redacted
Logs, Tracing, Error Reports und Analytics enthalten keine Tokens, Cookies, API Keys oder PII.
Revocation Story existiert
Für JWT, Sessions und API Keys gibt es ein klares Modell für Revocation, Rotation und forced logout.
In Bun ist es leicht, einen schnellen Auth Wrapper zu schreiben. Schwieriger ist Auth-Middleware, die Authentication und Authorization nicht vermischt, nicht zwischen Tenants leakt, keine Secrets loggt, keinen unnötigen DB Lookup bei jedem Request erzeugt und einen sauberen Error Contract hat.
JWT, Sessions und API Keys konkurrieren nicht als „besser“ und „schlechter“. Sie lösen unterschiedliche Aufgaben. JWT ist praktisch für stateless access, Sessions für Browser UX und kontrollierten Logout, API Keys für Integrationen. In Production braucht man oft Hybrid, aber mit einheitlichem Audit und Policy Layer.
Eine richtige Bun Auth Pipeline sieht simpel aus: extract, verify, resolve subject, resolve tenant, attach context, continue oder reject. Alles andere muss explizit designt, getestet und gemessen werden.
Nicht immer. JWT ist nützlich für stateless access und Service-to-Service-Szenarien, aber Revocation ist schwieriger. Sessions passen besser zu Browser SaaS, wo kontrollierter Logout, Secure Cookies und ein Session Store nötig sind. Die Wahl hängt von Client, Threat Model und Revocation-Anforderungen ab. [4][5]
Ja. Natives `Bun.serve` erlaubt Auth als Funktionskomposition rund um `Request`/`Response`. Aber du bist selbst verantwortlich für Context, Errors, Reihenfolge, Tests und Security Policy.
`401` für missing/invalid credential: kein Token, session expired, invalid signature, API key nicht gefunden. `403` für ein gültiges Credential ohne Permission, Tenant Access oder required Scope.
Im request-scoped Auth Context nach Prüfung von Credential und Membership. Vertraue `x-tenant-id` nicht als Source of Truth. Header oder Path Param kann der requested tenant sein, aber Middleware muss prüfen, dass das Subject Zugriff darauf hat.
Nein. Authorization Headers, Cookies, Refresh Tokens und API Keys sollten redacted werden. Logge request id, subject id, tenant id, auth method und error class, aber nicht das Credential.
Zeige den vollständigen API Key nur einmal bei der Erstellung, speichere einen Hash, halte einen kurzen Prefix für Lookup, und ergänze owner, scopes, environment, created/last used/revoked metadata sowie eine Rotation Policy.
Diese Quellen bestätigen das Verhalten der Bun Cookie API, Hono/Elysia Auth Middleware/Plugins und die Security Baseline für JWT und Session Management.
PAS7 Studio kann helfen, Auth-Middleware für Bun, Hono oder Elysia zu designen: JWT-/Session-/API-Key-Modell, Tenant Context, Scopes, Secure Cookies, Rotation, Observability und Security Review.
Das ist besonders nützlich für SaaS, Internal Platforms, B2B APIs und Migrationen von Express/Fastify, bei denen Auth Behavior bereits über Middleware, Guards und Helpers verteilt ist.
Auth Middleware in Bun.js: JWT, Sessions, API Keys und Multi-Tenant Context
Verwandte Artikel
AI Assistant Entwicklung Kosten 2026: RAG, Knowledge Base, Integrationen und Support
Praktischer Leitfaden zu Kosten fuer AI Assistants: RAG, Knowledge Base, Channels, Tool Use, Guardrails, Evaluations, Monitoring und Support.
KI fur Landingpage-Entwicklung: wo sie Launches beschleunigt und wo sie Conversion schadet
Eine praxisnahe Analyse zur Nutzung von KI fur Landingpages: v0, Webflow AI, Builder.io, Framer-ahnliche Builder, UX-Generierung, Copy, SEO, Personalisierung, A/B-Tests, Template-Risiken, Accessibility, Security und technischer Schuldenaufbau.
AI SEO / GEO im Jahr 2026: Ihre nächsten Kunden sind nicht Menschen — sondern Agents
Suche verschiebt sich von Klicks zu Antworten. Bots und AI-Agents crawlen, zitieren, empfehlen — und kaufen zunehmend. Erfahren Sie, was AI SEO / GEO bedeutet, warum klassisches SEO nicht mehr reicht und wie PAS7 Studio Marken im agentischen Web sichtbar macht.
Der leistungsstärkste Chip von Apple? M5 Pro und M5 Max brechen Rekorde
Eine Analyse zu Apple M5 Pro und M5 Max im März 2026. Wir zeigen, warum diese Chips als die stärksten professionellen Laptop-SoCs von Apple gelten können, wie sie sich gegen M4 Pro, M4 Max, M1 Pro, M1 Max schlagen und was der Vergleich mit aktuellen Intel- und AMD-Chips zeigt.
Professionelle Entwicklung für Ihr Geschäft
Wir erstellen moderne Web-Lösungen und Bots für Unternehmen. Erfahren Sie, wie wir Ihnen helfen können, Ihre Ziele zu erreichen.