Files
pn-new-crm/src/lib/portal/auth.ts

73 lines
2.6 KiB
TypeScript
Raw Normal View History

import { SignJWT, jwtVerify } from 'jose';
import { cookies } from 'next/headers';
fix(audit-wave-11): auth-flow hardening (auth-flow-auditor) Address the two CRITICAL items from auth-flow-auditor plus the high-impact M10 open-redirect. **C1 — Password reset doesn't revoke existing sessions** CRM side: Better Auth has a built-in `emailAndPassword.revokeSessionsOnPasswordReset` flag — flip it on. Verified by reading password.mjs in node_modules/better-auth: this calls `internalAdapter.deleteSessions(userId)` after the password update commits. One-line fix, closes the canonical session-bumping gap on the CRM forgot-password flow. Portal side: the portal uses JWT sessions (not DB-side rows) so there's no `deleteSessions` to call. Add a per-user `password_changed_at` watermark column on `portal_users` and have `verifyPortalToken` reject any token whose `iat` predates the watermark. Updated on `resetPassword`, `changePortalPassword`, and `activateAccount` so every password mutation revokes outstanding cookies. Token shape gains a required `portalUserId` claim so the verify step can do the watermark lookup without an email-based join; legacy tokens (pre-Wave-11) lack it and are rejected → forces one re-login per portal user post-deploy (24h max delay since portal tokens already self-expire at 24h). Migration `0058_portal_password_revocation.sql` stamps existing rows to `now()` so no current session is invalidated by the schema change itself. **M10 — Portal login `?next=` open redirect** `portal/login/page.tsx` did `router.replace(next as never)` against unvalidated `searchParams.get('next')`. An attacker could send a victim to `/portal/login?next=https://evil.example` and the post-sign-in redirect would navigate cross-site. Add `safeNextPath()` that requires `/portal/...` prefix and rejects protocol-relative URLs; everything else falls back to `/portal/dashboard`. **Other auth-flow items confirmed resolved by earlier waves:** - H6 resolve-identifier enumeration: endpoint deleted in Wave 1 (replaced with sign-in-by-identifier which keeps the synthetic email behind a server-side proxy) Tests updated: portal-auth integration test mocks `db` so the new DB-watermark lookup in `verifyPortalToken` stays unit-pure. Tests 1315/1315 after `psql ALTER TABLE` to apply migration locally. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-13 12:52:17 +02:00
import { eq } from 'drizzle-orm';
import { db } from '@/lib/db';
import { portalUsers } from '@/lib/db/schema/portal';
const PORTAL_SECRET = new TextEncoder().encode(process.env.BETTER_AUTH_SECRET);
export const PORTAL_COOKIE = 'portal_session';
// BREAKING CHANGE (intentional): tokens issued before this change lack aud/iss
// and will be rejected by verifyPortalToken. Portal tokens are 24h-lived so
// existing sessions will be invalidated on deploy. Users simply re-login.
const PORTAL_AUD = 'portal';
const PORTAL_ISS = 'pn-crm';
export interface PortalSession {
clientId: string;
portId: string;
email: string;
fix(audit-wave-11): auth-flow hardening (auth-flow-auditor) Address the two CRITICAL items from auth-flow-auditor plus the high-impact M10 open-redirect. **C1 — Password reset doesn't revoke existing sessions** CRM side: Better Auth has a built-in `emailAndPassword.revokeSessionsOnPasswordReset` flag — flip it on. Verified by reading password.mjs in node_modules/better-auth: this calls `internalAdapter.deleteSessions(userId)` after the password update commits. One-line fix, closes the canonical session-bumping gap on the CRM forgot-password flow. Portal side: the portal uses JWT sessions (not DB-side rows) so there's no `deleteSessions` to call. Add a per-user `password_changed_at` watermark column on `portal_users` and have `verifyPortalToken` reject any token whose `iat` predates the watermark. Updated on `resetPassword`, `changePortalPassword`, and `activateAccount` so every password mutation revokes outstanding cookies. Token shape gains a required `portalUserId` claim so the verify step can do the watermark lookup without an email-based join; legacy tokens (pre-Wave-11) lack it and are rejected → forces one re-login per portal user post-deploy (24h max delay since portal tokens already self-expire at 24h). Migration `0058_portal_password_revocation.sql` stamps existing rows to `now()` so no current session is invalidated by the schema change itself. **M10 — Portal login `?next=` open redirect** `portal/login/page.tsx` did `router.replace(next as never)` against unvalidated `searchParams.get('next')`. An attacker could send a victim to `/portal/login?next=https://evil.example` and the post-sign-in redirect would navigate cross-site. Add `safeNextPath()` that requires `/portal/...` prefix and rejects protocol-relative URLs; everything else falls back to `/portal/dashboard`. **Other auth-flow items confirmed resolved by earlier waves:** - H6 resolve-identifier enumeration: endpoint deleted in Wave 1 (replaced with sign-in-by-identifier which keeps the synthetic email behind a server-side proxy) Tests updated: portal-auth integration test mocks `db` so the new DB-watermark lookup in `verifyPortalToken` stays unit-pure. Tests 1315/1315 after `psql ALTER TABLE` to apply migration locally. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-13 12:52:17 +02:00
/** Portal user id needed by verifyPortalToken to fetch
* passwordChangedAt for the iat-vs-watermark check. Mirrors what
* `portalUsers.id` resolves to. */
portalUserId: string;
}
export async function createPortalToken(session: PortalSession): Promise<string> {
return new SignJWT(session as unknown as Record<string, unknown>)
.setProtectedHeader({ alg: 'HS256' })
.setAudience(PORTAL_AUD)
.setIssuer(PORTAL_ISS)
.setExpirationTime('24h')
.setIssuedAt()
.sign(PORTAL_SECRET);
}
export async function verifyPortalToken(token: string): Promise<PortalSession | null> {
try {
const { payload } = await jwtVerify(token, PORTAL_SECRET, {
audience: PORTAL_AUD,
issuer: PORTAL_ISS,
});
fix(audit-wave-11): auth-flow hardening (auth-flow-auditor) Address the two CRITICAL items from auth-flow-auditor plus the high-impact M10 open-redirect. **C1 — Password reset doesn't revoke existing sessions** CRM side: Better Auth has a built-in `emailAndPassword.revokeSessionsOnPasswordReset` flag — flip it on. Verified by reading password.mjs in node_modules/better-auth: this calls `internalAdapter.deleteSessions(userId)` after the password update commits. One-line fix, closes the canonical session-bumping gap on the CRM forgot-password flow. Portal side: the portal uses JWT sessions (not DB-side rows) so there's no `deleteSessions` to call. Add a per-user `password_changed_at` watermark column on `portal_users` and have `verifyPortalToken` reject any token whose `iat` predates the watermark. Updated on `resetPassword`, `changePortalPassword`, and `activateAccount` so every password mutation revokes outstanding cookies. Token shape gains a required `portalUserId` claim so the verify step can do the watermark lookup without an email-based join; legacy tokens (pre-Wave-11) lack it and are rejected → forces one re-login per portal user post-deploy (24h max delay since portal tokens already self-expire at 24h). Migration `0058_portal_password_revocation.sql` stamps existing rows to `now()` so no current session is invalidated by the schema change itself. **M10 — Portal login `?next=` open redirect** `portal/login/page.tsx` did `router.replace(next as never)` against unvalidated `searchParams.get('next')`. An attacker could send a victim to `/portal/login?next=https://evil.example` and the post-sign-in redirect would navigate cross-site. Add `safeNextPath()` that requires `/portal/...` prefix and rejects protocol-relative URLs; everything else falls back to `/portal/dashboard`. **Other auth-flow items confirmed resolved by earlier waves:** - H6 resolve-identifier enumeration: endpoint deleted in Wave 1 (replaced with sign-in-by-identifier which keeps the synthetic email behind a server-side proxy) Tests updated: portal-auth integration test mocks `db` so the new DB-watermark lookup in `verifyPortalToken` stays unit-pure. Tests 1315/1315 after `psql ALTER TABLE` to apply migration locally. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-13 12:52:17 +02:00
const session = payload as unknown as PortalSession & { iat?: number };
// auth-flow-auditor C1 (portal half): reject tokens issued before
// the user's last password change so a stolen cookie stops working
// after the legitimate owner does the forgot-password dance. The
// portalUserId claim is required for the lookup; tokens issued by
// the pre-C1 codepath lack it and are rejected on that grounds
// alone (forces re-login post-deploy, 24h max delay).
if (!session.portalUserId || !session.iat) return null;
const user = await db.query.portalUsers.findFirst({
where: eq(portalUsers.id, session.portalUserId),
columns: { passwordChangedAt: true, isActive: true },
});
if (!user || !user.isActive) return null;
const iatSeconds = session.iat;
const watermarkSeconds = Math.floor(user.passwordChangedAt.getTime() / 1000);
if (iatSeconds < watermarkSeconds) return null;
return session;
} catch {
return null;
}
}
export async function getPortalSession(): Promise<PortalSession | null> {
const cookieStore = await cookies();
const token = cookieStore.get(PORTAL_COOKIE)?.value;
if (!token) return null;
return verifyPortalToken(token);
}