@payez/next-mvp 4.4.7 → 4.4.9

package/dist/lib/nextauth-secret.js

@@ -0,0 +1,141 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.resolveNextAuthSecret = resolveNextAuthSecret;
+/**
+ * resolveNextAuthSecret - COMPATIBILITY SHIM (restored 2026-09-30, PAY-2005 / N7).
+ *
+ * ---------------------------------------------------------------------------
+ * WHY THIS FILE EXISTS, AND WHY IT IS A SHIM RATHER THAN A FEATURE
+ * ---------------------------------------------------------------------------
+ * The NextAuth-era broker secret resolver was DELETED in
+ *     4d3d29e6  "feat!: Better Auth 4.0.0 — NextAuth fully removed"
+ * and it is intentionally NOT coming back as first-class API: this package is
+ * Better Auth now, and new apps must not resolve a NextAuth secret at all.
+ *
+ * It is restored here ONLY because ONE consumer is still mid-migration and cannot
+ * take the 4.4.x bump without it:
+ *
+ *   CONSUMER THAT NEEDS THIS: the customer portal
+ *   (`payez_idp_admin_web` / VibeID-Customer-Portal). It is pinned at
+ *   @payez/next-mvp 4.0.46 and still runs BOTH next-auth@4.24 and better-auth; its
+ *   `src/lib/server-session.ts` and `src/lib/session-token.ts` (and 5 route files)
+ *   import `resolveNextAuthSecret` from here. Without this export, bumping the
+ *   portal to 4.4.x breaks its build. BAPert ruled (68003) to ship this scoped
+ *   shim rather than force the portal's full NextAuth->BetterAuth migration
+ *   tonight. That migration is tracked as its own card; WHEN IT LANDS, DELETE
+ *   THIS FILE.
+ *
+ * DO NOT add new consumers. If you are starting an app, use Better Auth's own
+ * secret handling; you do not need this.
+ *
+ * ---------------------------------------------------------------------------
+ * BEHAVIOUR (faithful to the 4.0.46 implementation, with one deliberate change)
+ * ---------------------------------------------------------------------------
+ * Priority: (1) process.env.NEXTAUTH_SECRET if set; (2) fetch from the IDP via a
+ * signed client assertion; (3) cache in-memory 5 min and stamp NEXTAUTH_SECRET.
+ *
+ * DELIBERATE CHANGE, 4.0.46 -> here: 4.0.46 validated the fetched secret with
+ * `validateNextAuthSecret`, which this package's 4.4.x no longer exports (it was
+ * renamed to `validateAuthSecret` with an IDENTICAL body). The shim calls
+ * `validateAuthSecret` - same predicate, current name - so there is no second
+ * copy of the rule. The validation semantics are unchanged.
+ *
+ * SERVER-ONLY: the IDP handshake and NEXTAUTH_SECRET are server concerns.
+ */
+require("server-only");
+const node_crypto_1 = require("node:crypto");
+const secret_validation_1 = require("./secret-validation");
+let cachedSecret = null;
+let lastFetchedAt = 0;
+const CACHE_TTL_MS = 5 * 60 * 1000;
+/**
+ * Resolve the NextAuth secret (server-only).
+ *
+ * Priority:
+ * 1) Use process.env.NEXTAUTH_SECRET if present (allows overrides/production)
+ * 2) Fetch from the IDP broker endpoint - the IDP handles all Key Vault/signing
+ * 3) Cache result in-memory and set process.env.NEXTAUTH_SECRET for later calls
+ */
+async function resolveNextAuthSecret() {
+    // Check if already in environment
+    if (process.env.NEXTAUTH_SECRET && process.env.NEXTAUTH_SECRET.trim() !== '') {
+        return process.env.NEXTAUTH_SECRET;
+    }
+    // Check if cached and fresh (within 5 minutes)
+    if (cachedSecret && Date.now() - lastFetchedAt < CACHE_TTL_MS) {
+        return cachedSecret;
+    }
+    // Broker mode: fetch from the IDP (the IDP handles all Key Vault/signing)
+    const base = process.env.IDP_URL;
+    if (!base)
+        throw new Error('IDP_URL environment variable is required');
+    const clientIdStr = process.env.CLIENT_ID;
+    if (!clientIdStr || clientIdStr.trim() === '') {
+        throw new Error('CLIENT_ID is required (e.g., "ideal_resume_website")');
+    }
+    // Step 1: ask the IDP to sign a client assertion (the IDP holds the keys, not us)
+    const signingUrl = `${base.replace(/\/$/, '')}/api/ExternalAuth/sign-client-assertion`;
+    const signingResp = await fetch(signingUrl, {
+        method: 'POST',
+        headers: {
+            Accept: 'application/json',
+            'Content-Type': 'application/json',
+            'X-Client-Id': clientIdStr,
+            'X-Correlation-Id': (0, node_crypto_1.randomUUID)().replace(/-/g, ''),
+        },
+        body: JSON.stringify({
+            issuer: clientIdStr,
+            subject: clientIdStr,
+            audience: 'urn:payez:externalauth:nextauthsecret',
+            expires_in: 60,
+        }),
+        cache: 'no-store',
+    });
+    if (!signingResp.ok) {
+        const txt = await signingResp.text().catch(() => 'Unknown error');
+        throw new Error(`Failed to sign client assertion: ${signingResp.status} ${signingResp.statusText} - ${txt}`);
+    }
+    const signingBody = (await signingResp.json().catch(() => ({})));
+    const clientAssertion = signingBody?.data?.client_assertion ??
+        signingBody?.data?.clientAssertion ??
+        signingBody?.client_assertion ??
+        signingBody?.clientAssertion ??
+        signingBody?.data?.ClientAssertion ??
+        signingBody?.ClientAssertion;
+    if (!clientAssertion || typeof clientAssertion !== 'string') {
+        throw new Error('IDP did not return a valid signed client assertion');
+    }
+    // Step 2: use the signed assertion to fetch the NextAuth secret
+    const proxyUrl = `${base.replace(/\/$/, '')}/api/ExternalAuth/next-auth/secret`;
+    const proxyResp = await fetch(proxyUrl, {
+        method: 'POST',
+        headers: {
+            Accept: 'application/json',
+            'Content-Type': 'application/json',
+            'X-Client-Id': clientIdStr,
+            'X-Correlation-Id': (0, node_crypto_1.randomUUID)().replace(/-/g, ''),
+        },
+        body: JSON.stringify({ client_assertion: clientAssertion }),
+        cache: 'no-store',
+    });
+    if (!proxyResp.ok) {
+        const txt = await proxyResp.text().catch(() => 'Unknown error');
+        throw new Error(`Proxy error: ${proxyResp.status} ${proxyResp.statusText} - ${txt}`);
+    }
+    const proxyBody = (await proxyResp.json().catch(() => ({})));
+    const secret = proxyBody?.data?.secret ?? proxyBody?.secret;
+    // `configuration` is available from the IDP but deliberately not logged.
+    if (!secret || typeof secret !== 'string') {
+        throw new Error('Proxy did not return a valid NextAuth secret');
+    }
+    // Same predicate as 4.0.46's validateNextAuthSecret, under its current name.
+    const validation = (0, secret_validation_1.validateAuthSecret)(secret);
+    if (!validation.valid) {
+        throw new Error(`Fetched NextAuth secret failed validation: ${validation.reason}`);
+    }
+    cachedSecret = secret;
+    lastFetchedAt = Date.now();
+    process.env.NEXTAUTH_SECRET = secret;
+    console.log('[NEXTAUTH-SECRET] Resolved from IDP (length:', secret.length + ')');
+    return secret;
+}

package/dist/lib/safe-error-response.d.ts

@@ -65,3 +65,11 @@ export declare function projectResetTokenInvalid(json: unknown): boolean;
  * (the caller must be able to tell a refused password from a dead recovery session).
  */
 export declare function projectPasswordPolicyRules(json: unknown): string[] | undefined;
+/**
+ * PAY-2103 (AUTH-009 breached-password check): the IdP refuses a password found in a breach corpus with
+ * the typed code `password_breached` in its 400 validation envelope (error.code, or error.details.code,
+ * or a value[] entry while it settles). The reset-password route is ANONYMOUS, so only a BOOLEAN crosses
+ * (`password_breached: true`), never the code text: the page maps the boolean to its own sentence. Reads
+ * only the code, never IdP text.
+ */
+export declare function projectPasswordBreached(json: unknown): boolean;

package/dist/lib/safe-error-response.js

@@ -21,6 +21,7 @@ exports.projectPasswordPolicyDetails = projectPasswordPolicyDetails;
 exports.idpErrorEnvelope = idpErrorEnvelope;
 exports.projectResetTokenInvalid = projectResetTokenInvalid;
 exports.projectPasswordPolicyRules = projectPasswordPolicyRules;
+exports.projectPasswordBreached = projectPasswordBreached;
 const password_rules_1 = require("./password-rules");
 const str = (v) => (typeof v === 'string' ? v : undefined);
 /** Log an exception with a fresh correlationId and return the id for the response body. */
@@ -128,3 +129,29 @@ function projectPasswordPolicyRules(json) {
         return undefined;
     return (0, password_rules_1.knownPasswordRules)(details.rules);
 }
+/**
+ * PAY-2103 (AUTH-009 breached-password check): the IdP refuses a password found in a breach corpus with
+ * the typed code `password_breached` in its 400 validation envelope (error.code, or error.details.code,
+ * or a value[] entry while it settles). The reset-password route is ANONYMOUS, so only a BOOLEAN crosses
+ * (`password_breached: true`), never the code text: the page maps the boolean to its own sentence. Reads
+ * only the code, never IdP text.
+ */
+function projectPasswordBreached(json) {
+    if (!json || typeof json !== 'object')
+        return false;
+    const top = json;
+    const err = top.error && typeof top.error === 'object' ? top.error : {};
+    const direct = str(err.code) ?? str(top.code) ?? str(top.error_code);
+    if (direct?.toLowerCase() === 'password_breached')
+        return true;
+    const details = (err.details && typeof err.details === 'object' ? err.details : top.details && typeof top.details === 'object' ? top.details : null);
+    if (str(details?.code)?.toLowerCase() === 'password_breached')
+        return true;
+    // THE SHAPE THE IdP ACTUALLY SENDS (DotNetPert-Scout, PAY-2103 PR 850caa07a): error.details =
+    // { field:'new_password', code:'password_policy', rules:['password_breached'], requirements:[...] }.
+    // The breach is a member of rules[], not a code - the house envelope carries every password rule
+    // that way. Reading only a code would MISS the real refusal.
+    if (Array.isArray(details?.rules) && details.rules.some((r) => typeof r === 'string' && r.toLowerCase() === 'password_breached'))
+        return true;
+    return Array.isArray(details?.value) && details.value.some((v) => !!v && typeof v === 'object' && str(v.code)?.toLowerCase() === 'password_breached');
+}

package/dist/middleware/create-middleware.d.ts

@@ -99,7 +99,48 @@ export interface MvpMiddlewareOptions {
     bypassPaths?: string[];
     /** Paths exempt from RBAC checks (auth still enforced, just no page-permission check) */
     rbacExemptPaths?: string[];
+    /**
+     * PAY-1882 step 4 - how this app treats a producer that reports the session's
+     * revocation status as `'unknown'` (a Vibe read that FAILED: non-OK, timeout,
+     * throw - the status could not be determined).
+     *
+     *   'closed' (DEFAULT) - an unknown revocation status is NOT viable; the
+     *                        session is force-invalidated and the user re-auths.
+     *                        This is Jon's PAY-1880 ruling (option A, fail closed),
+     *                        2026-09-27, and BAPert 66316/66320 restates it for
+     *                        step 4. Consequence, accepted explicitly: a Vibe
+     *                        outage signs this app's users out. 'not_configured'
+     *                        also fails closed here - both live consumers ARE
+     *                        configured (BAPert 66356), so for them it means a
+     *                        misconfiguration, not "no revocation source".
+     *   'open'             - an unknown OR not-configured status stays viable
+     *                        (availability over fail-closed). Per-app opt-out for a
+     *                        deployment with no revocation source, or the two live
+     *                        consumers while Jon decides.
+     *
+     * Neither mode changes `'revoked'` (always force-invalid) or an ABSENT
+     * `revocationStatus` (an older producer - unchanged behaviour, so no consumer
+     * is signed out for not implementing the check).
+     */
+    revocationFailMode?: 'closed' | 'open';
 }
 /** Login error code for a pre-2FA session that expired before the code was verified (PAY-884). */
 export declare const TWO_FACTOR_TIMEOUT_ERROR = "TwoFactorTimeout";
 export declare function createMvpMiddleware(options?: MvpMiddlewareOptions): (request: NextRequest) => Promise<NextResponse>;
+/**
+ * The revocation decision, as a pure function (PAY-1882 step 4, NightHawk 66392).
+ *
+ * Separate + exported so the B1 defect is testable with a REAL mutant: the bug was
+ * that `data.forceInvalid === true` was read BEFORE revocationFailMode, so a
+ * producer that folds 'unknown' into forceInvalid made the 'open' lever dead.
+ *
+ * RULE: when the producer supplies `revocationStatus`, it is AUTHORITATIVE - the
+ * decision is made from it plus failMode, and the folded booleans are ignored for
+ * 'unknown'/'not_configured'. The booleans are read ONLY when revocationStatus is
+ * absent (idealresume.online's older boolean-only route).
+ */
+export declare function decideForceInvalid(data: {
+    revocationStatus?: unknown;
+    forceInvalid?: unknown;
+    revoked?: unknown;
+}, revocationFailMode: 'closed' | 'open'): boolean;

package/dist/middleware/create-middleware.js

@@ -20,6 +20,7 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.TWO_FACTOR_TIMEOUT_ERROR = void 0;
 exports.createMvpMiddleware = createMvpMiddleware;
+exports.decideForceInvalid = decideForceInvalid;
 const server_1 = require("next/server");
 const route_config_1 = require("../auth/route-config");
 const safe_callback_1 = require("../auth/safe-callback");
@@ -317,6 +318,8 @@ function createMvpMiddleware(options = {}) {
     const refreshEndpoint = options.refreshEndpoint || '/api/auth/refresh';
     const bypassPaths = options.bypassPaths || [];
     const rbacExemptPaths = options.rbacExemptPaths || [];
+    // PAY-1882 step 4: default 'closed' (Jon's option A / BAPert 66316).
+    const revocationFailMode = options.revocationFailMode || 'closed';
     return async function middleware(request) {
         const { pathname, searchParams } = request.nextUrl;
         // =========================================================================
@@ -347,7 +350,7 @@ function createMvpMiddleware(options = {}) {
             // Has cookie - continue to viability check for 2FA enforcement
         }
         // --- Fetch session viability from internal API ---
-        const { sessionStatus, sessionPointer } = await checkViability(request, viabilityEndpoint, log);
+        const { sessionStatus, sessionPointer } = await checkViability(request, viabilityEndpoint, log, revocationFailMode);
         // --- Stale session (cookie exists but session doesn't): OBSERVE ONLY, DO NOT DECIDE ---
         //
         // *** CARD 349607. THIS BLOCK USED TO `return` HERE, AND THAT RETURN WAS A BYPASS. ***
@@ -409,8 +412,37 @@ function createMvpMiddleware(options = {}) {
         });
     };
 }
+/**
+ * The revocation decision, as a pure function (PAY-1882 step 4, NightHawk 66392).
+ *
+ * Separate + exported so the B1 defect is testable with a REAL mutant: the bug was
+ * that `data.forceInvalid === true` was read BEFORE revocationFailMode, so a
+ * producer that folds 'unknown' into forceInvalid made the 'open' lever dead.
+ *
+ * RULE: when the producer supplies `revocationStatus`, it is AUTHORITATIVE - the
+ * decision is made from it plus failMode, and the folded booleans are ignored for
+ * 'unknown'/'not_configured'. The booleans are read ONLY when revocationStatus is
+ * absent (idealresume.online's older boolean-only route).
+ */
+function decideForceInvalid(data, revocationFailMode) {
+    const status = data.revocationStatus;
+    if (typeof status === 'string') {
+        if (status === 'revoked')
+            return true;
+        if (status === 'active')
+            return false;
+        // S1 (NightHawk 66409): ANY other string - 'unknown', 'not_configured', a
+        // typo like 'Revoked', 'error', or '' - is treated as 'unknown' (fail mode
+        // applies), NEVER as 'active'. Returning false here would let the first
+        // producer that emits an unexpected state silently switch revocation OFF -
+        // the exact PAY-1880 fail-open class. Only an explicit 'active' is viable.
+        return revocationFailMode === 'closed';
+    }
+    // No revocationStatus: an older boolean producer. Absence of both stays false.
+    return data.forceInvalid === true || data.revoked === true;
+}
 /** Check session viability via internal API */
-async function checkViability(request, endpoint, log) {
+async function checkViability(request, endpoint, log, revocationFailMode) {
     const sessionStatus = {
         exists: false,
         forceInvalid: false,
@@ -443,6 +475,46 @@ async function checkViability(request, endpoint, log) {
             sessionStatus.exists = data.authenticated ?? (!!data.sessionTokenId && data.reason !== 'session_not_found');
             sessionStatus.requires2FA = data.requires2FA || false;
             sessionStatus.twoFactorComplete = data.twoFactorComplete || false;
+            // --- Session revocation (PAY-1882 Step 4) ---
+            // Two producer spellings are honoured, because both exist on the wire:
+            //   - boolean `forceInvalid` / `revoked` (idealresume.online's route today)
+            //   - the three-state `revocationStatus` the package's own viability
+            //     handlers now emit (PAY-1882 step 4).
+            //
+            // RULING (Jon, via BAPert 66316): 'revoked' ALWAYS fails closed. 'unknown'
+            // (a FAILED Vibe read) fails closed by default and is the ONLY state that
+            // the per-app `revocationFailMode` option can relax to viable.
+            //
+            // Four producer states (BAPert 66320), with the fail-closed ruling for
+            // 'not_configured' added by BAPert 66356:
+            //   'active'         - Vibe read OK, not revoked  -> viable
+            //   'revoked'        - Vibe says revoked          -> force-invalid, ALWAYS
+            //   'unknown'        - read FAILED                -> force-invalid if 'closed'
+            //   'not_configured' - no revocation source       -> force-invalid if 'closed'
+            //
+            // WHY 'not_configured' FAILS CLOSED WHEN 'closed': both live consumers of
+            // this middleware (portal.keelauth.com / keelauth-portal, idealvibe.online)
+            // DO set IDP_URL + VIBE_CLIENT_ID + VIBE_HMAC_KEY (BAPert 66356, measured in
+            // their committed manifests + the graft pipeline's own secret check), so for
+            // them 'not_configured' can only mean a MISCONFIGURATION - revocation
+            // silently switched off is exactly the PAY-1880 fail-open bug. An app with
+            // no revocation source that genuinely wants availability sets
+            // revocationFailMode 'open'.
+            //
+            // A MISSING revocationStatus (an older producer) keeps today's behaviour,
+            // i.e. NOT force-invalid: absence must never sign out a population that
+            // never opted into the check.
+            //
+            // *** revocationStatus IS AUTHORITATIVE WHEN PRESENT (NightHawk 66392). ***
+            // The package's own producers emit `forceInvalid: revocationStatus ===
+            // 'revoked' || revocationStatus === 'unknown'`. If the boolean were read
+            // FIRST, `forceInvalid: true` would short-circuit before revocationFailMode
+            // was consulted, so `'open'` could never keep an 'unknown' session viable -
+            // the opt-out lever would be DEAD. So: when a producer supplies a
+            // revocations status, decide from it + failMode and ignore the folded
+            // booleans for unknown/not_configured. The booleans are read ONLY when
+            // revocationStatus is ABSENT (idealresume.online's older boolean route).
+            sessionStatus.forceInvalid = decideForceInvalid(data, revocationFailMode);
             sessionPointer.exists = sessionStatus.exists ?? false;
             sessionPointer.sessionTokenId = data.sessionTokenId ?? null;
             sessionPointer.expired = data.accessTokenExpired || false;

package/dist/routes/auth/viability.d.ts

@@ -14,6 +14,7 @@
  * @since auth-ready-v2
  */
 import { NextRequest, NextResponse } from 'next/server';
+import { type RevocationStatus } from '../../vibe/sessions';
 /**
  * GET /api/session/viability - Check if session is viable
  *
@@ -34,6 +35,9 @@ export declare function GET(req: NextRequest): Promise<NextResponse<{
     hasRefreshToken: boolean;
     authenticated: boolean;
     sessionTokenId: string | null;
+    revocationStatus: RevocationStatus;
+    forceInvalid: boolean;
+    revoked: boolean;
     tenantRequiresTwoFactor: boolean;
     userHasCompletedTenantTwoFactorRequirements: boolean;
     userStillNeedsTwoFactor: boolean;
@@ -49,6 +53,7 @@ export declare function GET(req: NextRequest): Promise<NextResponse<{
     viable: boolean;
     needsRefresh: boolean;
     authenticated: boolean;
+    revocationStatus: RevocationStatus;
     error: string;
     code: string;
     correlationId: string;

package/dist/routes/auth/viability.js

@@ -22,6 +22,7 @@ const session_store_1 = require("../../lib/session-store");
 const idp_client_config_1 = require("../../lib/idp-client-config");
 const safe_error_response_1 = require("../../lib/safe-error-response");
 const token_log_id_1 = require("../../lib/token-log-id");
+const sessions_1 = require("../../vibe/sessions");
 /**
  * Get tenant-wide 2FA requirement from cached client config (from broker handshake)
  */
@@ -248,6 +249,41 @@ async function GET(req) {
         const oauthSessionNeedsTwoFactor = session?.mfaSignalPresent === true &&
             session?.mfaVerified === false &&
             !(session.idpRefreshToken || session?.refreshToken);
+        // --- Session revocation status (PAY-1882 step 4 producer half) ---
+        /*
+         * Resolve the four-state revocation status for this user (BAPert 66320).
+         * Read it HERE, above every authenticated return, so all three responses
+         * carry the SAME value - the same discipline as nextStep above.
+         *
+         * The middleware fails CLOSED by default on 'unknown' (a failed Vibe read)
+         * and always on 'revoked'; 'active' and 'not_configured' stay viable. A
+         * consumer that does NOT read revocationStatus is unaffected - absent is not
+         * revoked - so shipping this changes nothing for them until they opt in.
+         */
+        let revocationStatus = 'not_configured';
+        if (session) {
+            // BAPert 66480 condition 2 / ruling (ii) 66700: the numeric IdP id comes from
+            // the token's own `sub` claim FIRST (session.userId can be an email).
+            const revocationUserId = (0, sessions_1.resolveNumericIdpUserId)(session, session.idpAccessToken);
+            if (revocationUserId > 0) {
+                try {
+                    revocationStatus = await (0, sessions_1.getRevocationStatus)(revocationUserId, sessionToken);
+                }
+                catch {
+                    // getRevocationStatus does not throw by contract, but never let a
+                    // revocation probe take down the viability answer: fail closed.
+                    revocationStatus = 'unknown';
+                }
+            }
+            else {
+                // N1 (NightHawk 66392): a session exists but carries no usable numeric
+                // IdP id, so the check could not run -> 'unknown' (could not determine),
+                // NOT 'not_configured' (no revocation source).
+                // BAPert 66480 condition 1: emit ONE WARN (shape only) so a non-numeric
+                // id surfaces as a log line, not an unexplained sign-out.
+                revocationStatus = (0, sessions_1.warnNonNumericUserId)(sessionToken, session.userId);
+            }
+        }
         // Check access token expiry
         const now = Math.floor(Date.now() / 1000);
         // 240654 addendum 2: fall back to the Redis session's own expiry.
@@ -292,6 +328,11 @@ async function GET(req) {
                 needsRefresh: true,
                 authenticated: true,
                 sessionTokenId: sessionToken ? (0, token_log_id_1.tokenLogId)(sessionToken) : null,
+                // Session revocation (PAY-1882 step 4): the four-state status, plus the
+                // boolean the middleware's existing force-invalid branch already reads.
+                revocationStatus,
+                forceInvalid: revocationStatus === 'revoked' || revocationStatus === 'unknown',
+                revoked: revocationStatus === 'revoked',
                 // Clear names for middleware decision-making
                 tenantRequiresTwoFactor,
                 userHasCompletedTenantTwoFactorRequirements,
@@ -363,6 +404,10 @@ async function GET(req) {
                 twoFactorComplete: userHasCompletedTenantTwoFactorRequirements,
                 accessTokenExpired: true,
                 reason: 'Token expired',
+                // Session revocation (PAY-1882 step 4) - same value on every return.
+                revocationStatus,
+                forceInvalid: revocationStatus === 'revoked' || revocationStatus === 'unknown',
+                revoked: revocationStatus === 'revoked',
                 // RBAC fields
                 roles: session?.roles || [],
                 clientId: resolveClientId(session?.idpClientId),
@@ -375,6 +420,10 @@ async function GET(req) {
             hasRefreshToken,
             authenticated: true,
             sessionTokenId: sessionToken ? (0, token_log_id_1.tokenLogId)(sessionToken) : null,
+            // Session revocation (PAY-1882 step 4) - same value on every return.
+            revocationStatus,
+            forceInvalid: revocationStatus === 'revoked' || revocationStatus === 'unknown',
+            revoked: revocationStatus === 'revoked',
             // Clear names
             tenantRequiresTwoFactor,
             userHasCompletedTenantTwoFactorRequirements,
@@ -398,6 +447,10 @@ async function GET(req) {
             viable: false,
             needsRefresh: false,
             authenticated: false,
+            // PAY-1882 step 4: an exception here means the status could not be read.
+            // Report 'unknown' (not a bare 500 with no revocation signal) so the
+            // middleware's fail-closed default applies rather than reading it as viable.
+            revocationStatus: 'unknown',
             error: 'Failed to check session',
             code: 'INTERNAL_ERROR',
             correlationId

package/dist/utils/api.d.ts

@@ -33,6 +33,12 @@ export declare function apiFetch<T>(url: string, options?: ApiOptions): Promise<
  */
 export declare const RECOVERY_EXPIRED_TEXT = "This reset link has expired or was already used. Start password recovery again.";
 export declare const RESET_NEUTRAL_TEXT = "We couldn't set that password. Check it meets the requirements shown and try again.";
+/**
+ * PAY-2103 (AUTH-009): the IdP refuses a password found in a breach corpus; the route projects a
+ * `password_breached: true` boolean, and the user reads this. Distinct from the policy sentence,
+ * which would wrongly tell them to re-read the requirements.
+ */
+export declare const RESET_BREACHED_TEXT = "This password appears in a known data breach. Choose a different one.";
 /**
  * Three tiers for a 400/422 from reset (rigpert 60822, QAPert 60820), decided ONLY on codes the IdP actually sends:
  *   policy        details.code password_policy (projected by the handler as password_policy) -> the rule sentences

package/dist/utils/api.js

@@ -1,6 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.accountApi = exports.AccountApi = exports.RESET_NEUTRAL_TEXT = exports.RECOVERY_EXPIRED_TEXT = exports.ApiError = void 0;
+exports.accountApi = exports.AccountApi = exports.RESET_BREACHED_TEXT = exports.RESET_NEUTRAL_TEXT = exports.RECOVERY_EXPIRED_TEXT = exports.ApiError = void 0;
 exports.apiFetch = apiFetch;
 exports.resetFailureText = resetFailureText;
 const standardized_client_api_1 = require("../lib/standardized-client-api");
@@ -84,6 +84,12 @@ async function apiFetch(url, options = {}) {
  */
 exports.RECOVERY_EXPIRED_TEXT = 'This reset link has expired or was already used. Start password recovery again.';
 exports.RESET_NEUTRAL_TEXT = "We couldn't set that password. Check it meets the requirements shown and try again.";
+/**
+ * PAY-2103 (AUTH-009): the IdP refuses a password found in a breach corpus; the route projects a
+ * `password_breached: true` boolean, and the user reads this. Distinct from the policy sentence,
+ * which would wrongly tell them to re-read the requirements.
+ */
+exports.RESET_BREACHED_TEXT = 'This password appears in a known data breach. Choose a different one.';
 /**
  * Three tiers for a 400/422 from reset (rigpert 60822, QAPert 60820), decided ONLY on codes the IdP actually sends:
  *   policy        details.code password_policy (projected by the handler as password_policy) -> the rule sentences
@@ -196,7 +202,9 @@ class AccountApi {
             const policy = !!body?.password_policy;
             const rules = (0, password_rules_1.knownPasswordRules)(body?.password_policy?.rules);
             const tokenInvalid = body?.reset_token_invalid === true;
-            const err = new Error(resetFailureText(res.status, rules, policy, tokenInvalid));
+            // PAY-2103: a breached password is its own outcome, not a policy refusal.
+            const breached = body?.password_breached === true;
+            const err = new Error(breached ? exports.RESET_BREACHED_TEXT : resetFailureText(res.status, rules, policy, tokenInvalid));
             if (rules.length)
                 err.rules = rules;
             if ((res.status === 400 || res.status === 422) && tokenInvalid && !policy)

package/dist/vibe/sessions.d.ts

@@ -144,8 +144,95 @@ export declare function isSessionValid(sessionId: number, accessToken: string):
  * @param accessToken - Access token for auth
  * @param sessionTokenHash - Optional token hash to check specific session
  * @returns Revoked session info if enforcement needed, null otherwise
+ *
+ * @deprecated PAY-2037 step 1 (BAPert 69153): kept so no consumer breaks. It is a thin call into the
+ * same hash-first decision as getRevocationStatus; prefer getRevocationStatus, which distinguishes
+ * a failed read ('unknown') from 'active' instead of throwing.
+ */
+export declare function checkSessionRevocation(idpUserId: number, _accessToken: string, sessionTokenHash?: string): Promise<IVibeLoginSession | null>;
+/** The four states a viability producer can report (BAPert 66320). */
+export type RevocationStatus = 'active' | 'revoked' | 'unknown' | 'not_configured';
+/**
+ * Hash a session token the same way record-login stores it.
+ * SHA256 hex, 64 chars. This must stay byte-identical to
+ * `hashSessionToken` in the consumers (idealresume.online/lib/session-token-hash.ts)
+ * or per-session matching silently falls back to the user-wide path.
+ */
+export declare function hashSessionToken(token: string): string;
+/**
+ * BAPert 66480 condition 2 (ruling (ii), 66700; corrected per QAPert 66729):
+ * resolve the NUMERIC IdP user id the Vibe query filters on.
+ *
+ * *** DO NOT READ `sub` FOR THE USER ID. *** In the IdP's bearer token `sub` is the
+ * USERNAME, not the id: AESGCM_Encryption.cs:815 writes `{ "sub", payload.Username }`
+ * and :822 writes `{ "user_id", payload.UserId.ToString() }`. A username is commonly
+ * an email, so reading `sub` yields 0 for the common case - and for a username that
+ * happens to be all digits it yields the WRONG id, which getRevocationStatus answers
+ * 'active' for a user with no rows: a fail-OPEN.
+ *
+ * Resolution order:
+ *   1. the token's `user_id` claim, when it is all digits;
+ *   2. a digits-only session.userId / session.user.id;
+ *   3. otherwise 0 (unresolvable), which the caller reports as 'unknown' (fail closed).
+ *
+ * session.userId is not a safe source on its own either: session-store.ts:143 falls
+ * back to user.email, and better-auth.ts stringifies whichever id it finds.
+ */
+export declare function resolveNumericIdpUserId(session: unknown, accessToken?: string): number;
+/**
+ * Public entry point for the twins: call this when a session exists but its
+ * userId is not a usable numeric IdP id. Returns 'unknown' (fail closed) and
+ * emits the once-per-session WARN. Shape only, never the value.
+ */
+export declare function warnNonNumericUserId(sessionToken: string | undefined, rawUserId: unknown): 'unknown';
+/**
+ * HMAC-ONLY session read for the revocation check (PAY-1882 step 4).
+ *
+ * *** DO NOT "SIMPLIFY" THIS ONTO vibeProxyRequest/getUserSessions. ***
+ * It is deliberately separate and deliberately sends NO Authorization header.
+ *
+ * WHY: the twin this must match is idealresume.online's checkSessionRevocation
+ * read. That repo's vibe-client adds `Authorization: Bearer` ONLY for member
+ * paths (`path.startsWith('/v1/my/')`) - see idealresume.online/lib/vibe-client.ts
+ * :207-210 - so its /v1/collections/.../query for this check goes out HMAC-only.
+ * The comment at vibe-client.ts:188-206 there records why: a bearer on the
+ * collections path caused USER_REQUIRED and broke signups. getUserSessions()
+ * here ALWAYS sends the bearer, so it cannot stand in for this read without
+ * changing the credential the two twins are supposed to share.
+ *
+ * BAPert 66344 (option a): match the twin, HMAC-only.
+ *
+ * Also distinguishes a FAILED read from an EMPTY one - getUserSessions()
+ * collapses a proxy outage and "user has no sessions" to `[]`, which is
+ * fail-OPEN for a revocation decision. Returns `ok:false` on an outage so the
+ * caller fails closed, and `ok:true, sessions:[]` only for a healthy empty.
+ */
+export declare function readSessionRevocationHmac(idpUserId: number): Promise<{
+    ok: boolean;
+    sessions: IVibeLoginSession[];
+}>;
+/**
+ * Determine whether a session is revoked, with an explicit UNKNOWN state
+ * (PAY-1882 step 4 producer half).
+ *
+ * States:
+ *   'not_configured' - this deployment has no revocation source (IDP_URL /
+ *                      VIBE_CLIENT_ID / VIBE_HMAC_KEY absent). Viable; today's
+ *                      behaviour. Logged once, not per request.
+ *   'unknown'        - revocation IS configured but the read FAILED (non-OK,
+ *                      timeout, throw). Enforcing middleware fails this CLOSED
+ *                      by default (revocationFailMode 'closed'); a Vibe-less
+ *                      consumer is 'not_configured', not 'unknown', so it is not
+ *                      signed out.
+ *   'revoked'        - the session's own token hash matches a revoked row, or
+ *                      the user has no active session at all.
+ *   'active'         - read OK and the session is not revoked.
+ *
+ * @param idpUserId - The user's IDP ID
+ * @param sessionToken - The live session token; hashed to match the stored row.
+ *                       When absent, the user-wide check applies (legacy path).
  */
-export declare function checkSessionRevocation(idpUserId: number, accessToken: string, sessionTokenHash?: string): Promise<IVibeLoginSession | null>;
+export declare function getRevocationStatus(idpUserId: number, sessionToken?: string): Promise<RevocationStatus>;
 /**
  * Get session statistics for admin dashboard.
  *