Auth és session Nuxt-módra

10.1Miért nem ültethető át a megszokott minta

A passport + express-session + Redis hármas nem azért nem működik, mert „a Cloudflare furcsa”, hanem mert három konkrét feltételezésre épül, amiből egy sem áll:

A jó hír: a Nuxt-ökoszisztémában van erre kialakult, kényelmes megoldás, és a mentális modell egyszerűbb, mint a régi.

10.2A négy stratégia — és amit válassz

10.3nuxt-auth-utils — a teljes folyamat

Ez a Nuxt-világ de facto session-megoldása, és pontosan a fenti sealed-cookie mintát valósítja meg.

npx nuxi module add auth-utils

# .env — legalább 32 karakter. Élesben ez SECRET, nem env-változó!
NUXT_SESSION_PASSWORD=egy-legalabb-32-karakteres-veletlen-titok

Bejelentkezés

// server/api/auth/login.post.ts
export default defineEventHandler(async (event) => {
  const { email, password } = await readValidatedBody(event, loginSchema.parse)
  const db = useDb(event)

  const user = await db.query.users.findFirst({ where: eq(users.email, email.toLowerCase()) })

  // ⚠ ugyanaz az üzenet és nagyjából ugyanaz az idő, létezik-e a felhasználó vagy sem
  if (!user || !(await verifyPassword(user.passwordHash, password))) {
    throw createError({ statusCode: 401, statusMessage: 'Hibás email vagy jelszó' })
  }

  const membership = await loadDefaultMembership(db, user.id)
  if (!membership) throw createError({ statusCode: 403, statusMessage: 'Nincs aktív munkaterület' })

  // a session TARTALMA — csak a minimum, mert minden kérésben utazik
  await setUserSession(event, {
    user: { id: user.id, name: user.name },
    tenantId: membership.tenantId,
    role:     membership.role,
    epoch:    user.sessionEpoch,      // ← a visszavonáshoz, lásd 10.7
    loggedInAt: Date.now(),
  })

  return { ok: true }
})

Kliensoldal

<script setup lang="ts">
const { loggedIn, user, clear, fetch: refreshSession } = useUserSession()

async function onSubmit() {
  await $fetch('/api/auth/login', { method: 'POST', body: form })
  await refreshSession()          // a kliensoldali session-állapot frissítése
  await navigateTo('/app')
}
</script>

OAuth-hoz kész handlerek vannak (defineOAuthGoogleEventHandler, defineOAuthGitHubEventHandler és több tucat másik), onSuccess callbackkel — abban ugyanúgy setUserSession-t hívsz. Ez az egyik legnagyobb kényelmi különbség a passporthoz képest: nincs strategy-konfiguráció, csak egy handler-fájl.

10.4Jelszókezelés Workers-en — ami 2026-ra megváltozott

Ha korábban olvastál Workers-es auth-ról, valószínűleg ezt láttad: „a bcrypt nem működik, használj Web Crypto PBKDF2-t”. Ez ma már árnyaltabb:

Vagyis a legegyszerűbb út ma az, hogy a modul beépített segédfüggvényeit használod:

// regisztráció
const passwordHash = await hashPassword(password)

// bejelentkezés
const ok = await verifyPassword(user.passwordHash, password)

// és ha a hash-paraméterek elavultak, csendben frissítjük sikeres belépéskor
if (ok && passwordNeedsRehash(user.passwordHash)) {
  await db.update(users)
    .set({ passwordHash: await hashPassword(password) })
    .where(eq(users.id, user.id))
}

Migráció a régi bcrypt-hash-ekről

Ha a mostani Express-appod bcrypttel hasheli a jelszavakat, a hash-eket nem tudod „átalakítani” — csak bejelentkezéskor tudsz újrahashelni, mert csak akkor van meg a nyílt jelszó:

async function checkAndMigrate(db, user, password: string) {
  // ① régi formátum? ellenőrizzük bcryptjs-sel (drága, de csak átmenetileg)
  if (user.passwordHash.startsWith('$2')) {
    const bcrypt = await import('bcryptjs')          // dinamikus import: ne nőjön a bundle
    if (!(await bcrypt.compare(password, user.passwordHash))) return false

    // ② sikeres belépés → átírjuk az új formátumra
    await db.update(users)
      .set({ passwordHash: await hashPassword(password) })
      .where(eq(users.id, user.id))
    return true
  }

  return await verifyPassword(user.passwordHash, password)
}

10.5A védelem középponti mintája

Itt jön össze a 4., 6. és 8. modul. Három réteg, és mindegyiknek külön dolga van:

// server/utils/auth.ts — minden védett végpont ezzel kezdődik

export async function requireSession(event: H3Event) {
  const session = await requireUserSession(event)   // 401, ha nincs
  return {
    userId:   session.user.id,
    tenantId: session.tenantId as string,
    role:     session.role as Role,
  }
}

// és a tenant-határ: a session tenantja EGYEZZEN az útvonaléval
export async function requireTenant(event: H3Event) {
  const s = await requireSession(event)
  const routeTenant = event.context.tenant       // a 4. modul middleware-éből

  if (routeTenant && routeTenant.id !== s.tenantId) {
    // NEM 403 — a 404 nem árulja el, hogy létezik-e az a munkaterület
    throw createError({ statusCode: 404, statusMessage: 'Nem található' })
  }
  return s
}

export function requireRole(s: { role: Role }, needed: Role) {
  if (!hasAtLeast(s.role, needed)) {
    // itt viszont 403 a helyes: a tenanton BELÜL nincs jogosultsága
    throw createError({ statusCode: 403, statusMessage: 'Nincs jogosultság' })
  }
}

// server/api/projects/[id].delete.ts — így néz ki egy védett végpont
export default defineEventHandler(async (event) => {
  const s = await requireTenant(event)
  requireRole(s, 'admin')

  const deleted = await useDb(event).delete(projects)
    .where(and(
      eq(projects.id, getRouterParam(event, 'id')!),
      eq(projects.tenantId, s.tenantId),      // ← a tenant-feltétel MINDIG a lekérdezésben
    ))
    .returning({ id: projects.id })

  if (!deleted.length) throw createError({ statusCode: 404 })
  setResponseStatus(event, 204)
})

10.6CSRF

Cookie-alapú session-nél ez nem opcionális. Két lépés, és mindkettő olcsó:

// ① a cookie-beállítás — nuxt.config.ts
export default defineNuxtConfig({
  runtimeConfig: {
    session: {
      name: '__Host-session',      // __Host- prefix: csak HTTPS, path=/, nincs domain
      cookie: {
        sameSite: 'lax',           // alapvédelem a keresztoldali POST ellen
        secure:   true,
        httpOnly: true,            // JS-ből nem olvasható
        path:     '/',
      },
    },
  },
})

// ② Origin-ellenőrzés minden mutáló kérésre — server/middleware/3.csrf.ts
const SAFE = new Set(['GET', 'HEAD', 'OPTIONS'])

export default defineEventHandler((event) => {
  if (SAFE.has(event.method)) return
  if (!event.path.startsWith('/api/')) return

  const origin = getHeader(event, 'origin')
  const host   = getRequestHost(event)

  // a böngésző mutáló kérésnél mindig küld Origint
  if (!origin || new URL(origin).host !== host) {
    throw createError({ statusCode: 403, statusMessage: 'Érvénytelen eredet' })
  }
})

10.7Kijelentkezés és session-visszavonás

A lezárt cookie egyetlen komoly gyengéje: amíg le nem jár, érvényes marad, akkor is, ha közben letiltottad a felhasználót. A „jelszóváltás után jelentkezzen ki mindenhonnan” követelményhez kell egy visszavonási mechanizmus. A legolcsóbb a revocation epoch:

// a users táblában van egy sessionEpoch INTEGER mező (alapból 0)
// jelszóváltás, kirúgás, „kilépés minden eszközön" → epoch++

// server/utils/auth.ts
export async function requireSession(event: H3Event) {
  const session = await requireUserSession(event)

  // nem minden kérésnél ellenőrzünk — csak ha a session „öreg"
  const ageMs = Date.now() - (session.checkedAt ?? session.loggedInAt)
  if (ageMs > 5 * 60_000) {
    const current = await getUserEpoch(event, session.user.id)   // KV vagy DB, cache-elve
    if (current !== session.epoch) {
      await clearUserSession(event)
      throw createError({ statusCode: 401, statusMessage: 'A munkamenet lejárt' })
    }
    await setUserSession(event, { checkedAt: Date.now() })    // merge, nem csere
  }

  return { userId: session.user.id, tenantId: session.tenantId, role: session.role }
}

Az ötperces ablak tudatos kompromisszum: a kérések túlnyomó része nulla extra I/O-val megy, a visszavonás pedig legfeljebb öt percen belül érvényesül. Ha ennél szigorúbb kell (például pénzügyi művelet előtt), akkor arra az egy végpontra kényszerítsd ki az azonnali ellenőrzést.

10.8Mi működik a könyvtárakból

Enterprise SSO — amit már most érdemes előkészíteni

Ha B2B SaaS-t építesz, előbb-utóbb jön a „mi Okta/Entra ID-vel akarunk belépni” kérés. Két olcsó döntés most:

• A tenantnak legyen egy „auth-mód” mezője (jelszó / OAuth / SSO) és egy domain-listája. Így később a bejelentkezési képernyő e-mail-domain alapján tud a helyes folyamathoz irányítani (home realm discovery) — anélkül, hogy az adatmodellt kellene bontani.
• A session ne kösse magát a jelszavas belépéshez. Ha a setUserSession hívása egy helyen van, és nem az feltételezi, hogy jelszó volt, akkor az SSO később csak egy újabb belépési pont ugyanahhoz.

10.9Éles indulás előtti checklist

10.10Ellenőrizd magad