Auth, session és tenant-identitás

17.1Miért más ez itt?

A Node-világban a session-kezelés jellemzően így nézett ki: a szerver memóriájában (vagy Redisben) van egy session-store, a kliens kap egy session-ID-t cookie-ban, és minden kéréskor kikeresed. Workersön ebből két dolog törik el:

• Nincs megbízható processz-memória (2. modul): az isolate bármikor eldobható, és több száz PoP-ban fut párhuzamosan — memóriában tartott session-store értelmezhetetlen.
• Nincs „közeli Redis": ha minden kérés egy központi store-hoz fordul, elveszted az edge előnyét — a felhasználó Sydney-ben van, a store Frankfurtban.

Ebből következik a modul központi döntése: hol él a session állapota?

17.2A négy session-stratégia

Aláírt cookie a gyakorlatban (Nuxt)

Nuxtban a nuxt-auth-utils pontosan ezt a mintát adja: lezárt (sealed) cookie-session, ami a Workers-runtime-ban is működik, mert csak Web Crypto kell hozzá.

export default defineEventHandler(async (event) => {
  const { email, password } = await readBody(event);
  const user = await verifyCredentials(event, email, password);   // lásd 17.4
  if (!user) throw createError({ statusCode: 401 });

  await setUserSession(event, {
    user:   { id: user.id, email: user.email },
    tenant: { id: user.tenant_id, role: user.role },   // a tenant a session RÉSZE
    loggedInAt: new Date().toISOString(),
  });
  return { ok: true };
});

A titok a NUXT_SESSION_PASSWORD (min. 32 karakter), ami secretként él (8. és 12. modul): .dev.vars lokálisan, wrangler secret put élesben.

17.3Jelszó-hashelés: mi működik a Workersön?

Itt van egy fontos runtime-korlát, amivel Node-ból érkezve szembe fogsz futni. A bcrypt natív bináris — nem fut isolate-ben (2. modul). Az argon2 ugyanígy. Ami működik:

const ITER = 210_000;   // igazítsd a CPU-budgetedhez, mérd meg! (9. modul)

export async function hashPassword(password: string) {
  const salt = crypto.getRandomValues(new Uint8Array(16));
  const key = await crypto.subtle.importKey(
    "raw", new TextEncoder().encode(password), "PBKDF2", false, ["deriveBits"]);
  const bits = await crypto.subtle.deriveBits(
    { name: "PBKDF2", salt, iterations: ITER, hash: "SHA-256" }, key, 256);

  return `pbkdf2$${ITER}$${b64(salt)}$${b64(new Uint8Array(bits))}`;
}

export async function verifyPassword(stored: string, password: string) {
  const [, iter, salt, hash] = stored.split("$");
  // … ugyanaz a derive, majd IDŐÁLLANDÓ összehasonlítás:
  return timingSafeEqual(computed, hash);
}

17.4A tenant-identitás: hol dől el, ki melyik tenant tagja?

Multitenant SaaS-ban az auth nem ér véget a „ki vagy?" kérdésnél — a lényeg a „melyik tenant nevében, milyen szerepkörrel?". Három forrásból jöhet a tenant, és ezt tudatosan kell eldönteni:

A helyes minta: a tenant-feloldás egyetlen middleware-ben történjen, egyszer, és onnantól a kontextusból jöjjön — soha ne minden endpoint oldja meg újra (13. modul elve):

export default defineEventHandler(async (event) => {
  if (!getRequestURL(event).pathname.startsWith("/api/")) return;

  const session = await getUserSession(event);
  if (!session?.user) return;                       // publikus végpont

  // 1) a hostból megpróbáljuk (custom domain / aldomain)
  const hostTenant = await tenantFromHost(event);

  // 2) ha van host-tenant, ellenőrizzük a TAGSÁGOT — ez a kulcslépés
  const tenantId = hostTenant?.id ?? session.tenant.id;
  if (hostTenant && hostTenant.id !== session.tenant.id) {
    const member = await useDb(event).prepare(
      "SELECT role FROM memberships WHERE user_id = ? AND tenant_id = ?"
    ).bind(session.user.id, hostTenant.id).first();
    if (!member) throw createError({ statusCode: 403 });
    event.context.role = member.role;
  } else {
    event.context.role = session.tenant.role;
  }

  event.context.tenantId = tenantId;                // innentől EZT használja mindenki
  event.context.userId   = session.user.id;
});

17.5Könyvtárak: mi működik a workerd-ben?

17.6Enterprise SSO — amikor az ügyfél SAML-t kér

Egy B2B SaaS életében biztosan eljön a pillanat, amikor egy nagy ügyfél azt mondja: „a mi felhasználóink az Okta/Entra ID/Google Workspace fiókjukkal lépjenek be". Négy út van:

1. OIDC magadtól. Ha az ügyfél OIDC-t (nem SAML-t) tud, ez teljesen kivitelezhető Workersen: authorization code flow + PKCE, a JWKS-t cache-eled KV-ben, a tokent Web Cryptóval validálod. Tenantonként tárolod az issuer/client_id/secret hármast.
2. SAML külső szolgáltatóval. A SAML XML-alapú, aláírás-ellenőrzéssel — implementálható, de nem szórakoztató, és biztonsági szempontból hibázni könnyű. Erre valók a dedikált szolgáltatók (pl. WorkOS-jellegű SSO-brókerek): ők beszélnek SAML-t az ügyféllel, neked OIDC-t vagy egyszerű API-t adnak.
3. Teljes auth-platform (Auth0/Clerk/…): mindent ők visznek, te tokent validálsz.
4. Cloudflare Access: ez a belső eszközeidre való (admin, staging — 9. modul), nem a végfelhasználói SSO-ra. Ne keverd össze a kettőt.

Amit az architektúrádban előre készíts elő, még mielőtt az első ügyfél kéri: a tenants táblában legyen hely az SSO-konfignak (sso_type, issuer, client_id, domain), és a login-folyamat tudjon email-domain alapján irányítani: ha valaki @acme.com címmel próbál belépni, és az acme tenantnál SSO van bekapcsolva, a jelszavas belépés helyett az ő identity providerükhöz kell átdobni. Ez a „home realm discovery", és utólag beépíteni sokkal fájdalmasabb.

17.7Gép-gép: API-kulcsok és service-to-service

• Ügyfél-API-kulcsok: soha ne nyersen tárold. A kulcsot generálod (crypto.getRandomValues), megmutatod egyszer, és a DB-be csak a hash kerül; ellenőrzéskor a beérkező kulcsot hasheled és úgy keresed. Legyen prefixe (sk_live_…), hogy felismerhető legyen a logokban és a titok-szkennerekben, és tárold hozzá a tenantot, a jogosultságokat és a lejáratot.
• Rate limit kulcsonként: a 7. modul DO-limitere itt is a helyes eszköz (kulcsonként vagy tenantonként), a zóna-szintű WAF-szabály pedig a durva védelem (9. modul).
• Belső Worker→Worker hívás: ne találj ki saját tokent — használj service bindinget (11. modul). A hívás nem megy ki az internetre, tehát nincs mit lehallgatni, és nincs mit hitelesíteni.
• Kimenő hívások partnerekhez: a titkok secretben (12. modul), a rotáció sorrendjére figyelve (8. modul).

17.8Checklist — mielőtt élesben auth-olsz

• A session-cookie HttpOnly, Secure, SameSite=Lax (vagy Strict), reális lejárattal.
• CSRF-védelem az állapotváltó kéréseknél (SameSite + token, ha cross-site űrlapod van).
• A jelszó-ellenőrzés időállandó összehasonlítást használ, és a hibaüzenet nem árulja el, hogy az email létezik-e.
• Bejelentkezési kísérletek korlátozása: zóna-szintű rate limit a /api/auth/login-ra (9. modul) és fiókonkénti számláló (DO).
• Turnstile a regisztráción és a jelszó-visszaállításon (16. modul).
• Tenant-izolációs teszt a tesztkészletben (11. modul).
• Kiléptetés minden eszközről: refresh-tokenek törlése + revocation epoch emelése.
• Audit-log a biztonsági eseményekre (belépés, jogosultság-változás, API-kulcs létrehozás) — strukturált logként (9. modul).

17.9Ellenőrizd magad