@payez/next-mvp 4.1.21 → 4.4.1

package/dist/pages/test-env/index.js

@@ -1,10 +1,56 @@
 "use strict";
 /**
- * Test Environment Pages
+ * ⚠️ TEST-ENVIRONMENT DEBUG PAGES — NONE OF THESE BELONG IN PRODUCTION. ⚠️
  *
- * Export debug pages for MVP consumers.
+ * ────────────────────────── READ BEFORE COPYING ANYTHING BELOW (QAPert 35000) ──────────────────────────
+ * This barrel is the SPREAD MECHANISM. It ships compiled into dist and into
+ * the .d.ts, so it reaches every consuming developer's editor as hover text,
+ * and the block below is a four-line copy-paste that mounts every debug page
+ * this package has. It previously carried no warning at all.
  *
- * Usage:
+ * NONE of these pages has an env gate of its own. Unlike the force-expire
+ * handler (ENABLE_TEST_ROUTES) or the idp-token route
+ * (ENABLE_TOKEN_INSPECTOR), a mounted page is reachable exactly as far as your
+ * middleware allows. MOUNTING IS THE GATE — so gate the WHOLE /test-env
+ * segment, per environment, not page by page.
+ *
+ * They are not equally dangerous. In descending order:
+ *   JwtInspectPage       WORST. Copy-to-clipboard for the LIVE SESSION TOKEN
+ *                        and ACCESS TOKEN. A session token is exactly the
+ *                        precondition the 246007 finding needs.
+ *   TestEnvPage          The index. Harmless alone, but it ADVERTISES the
+ *                        other three to anyone who reaches it.
+ *   RefreshTokenPage     Drives the destructive /api/test/force-expire.
+ *   EmergencyLogoutPage  Mildest. Self-inflicted, recoverable.
+ *
+ * ── THESE PAGES ARE NOW ENV-GATED, FAIL-CLOSED (249259, BAPert ruling 35321) ──
+ * SUPERSEDES the previous note here, which said a gate was impossible and that
+ * mounting was the only control. That was correct about the PAGES and wrong as
+ * a conclusion: it CANNOT be done inside these `'use client'` files, but it CAN
+ * be done in a server component wrapping them. That wrapper now ships, and it
+ * is what the four names below resolve to — see ./guarded.tsx.
+ *
+ *     ENABLE_TEST_ROUTES === 'true'   ->  the page renders
+ *     anything else, including unset  ->  notFound()
+ *
+ * It is the DEFAULT, not an opt-in sibling: BAPert's ruling was explicit that
+ * "an opt-in safety gate is one nobody opts into". The raw ungated components
+ * are NOT exported. Same import path, same component names, same signatures —
+ * consumers add one env var to their dev environments and change no code.
+ *
+ * ── MOUNTING IS STILL THE PRIMARY GATE ──────────────────────────────────────
+ * Do not read the env var as making mounting safe. The wrapper is a backstop
+ * for a mount that should not have happened. With ENABLE_TEST_ROUTES=true in an
+ * environment where these are mounted you have exactly the exposure 248991
+ * documented: a live session token, one click from the clipboard. If you are
+ * not actively debugging, DO NOT MOUNT THESE AT ALL — the safest configuration
+ * is still their absence, and the env var does not change that.
+ *
+ * Each page's own docstring carries the detail. If you are not actively
+ * debugging, DO NOT MOUNT THESE AT ALL — the safest configuration is their
+ * absence.
+ *
+ * Usage — TEST/DEV ENVIRONMENTS ONLY:
  * ```typescript
  * // app/test-env/page.tsx
  * export { TestEnvPage as default } from '@payez/next-mvp/pages/test-env';
@@ -21,12 +67,12 @@
  */
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.EmergencyLogoutPage = exports.RefreshTokenPage = exports.JwtInspectPage = exports.default = exports.TestEnvPage = void 0;
-var TestEnvPage_1 = require("./TestEnvPage");
-Object.defineProperty(exports, "TestEnvPage", { enumerable: true, get: function () { return TestEnvPage_1.TestEnvPage; } });
-Object.defineProperty(exports, "default", { enumerable: true, get: function () { return TestEnvPage_1.TestEnvPage; } });
-var JwtInspectPage_1 = require("./JwtInspectPage");
-Object.defineProperty(exports, "JwtInspectPage", { enumerable: true, get: function () { return JwtInspectPage_1.JwtInspectPage; } });
-var RefreshTokenPage_1 = require("./RefreshTokenPage");
-Object.defineProperty(exports, "RefreshTokenPage", { enumerable: true, get: function () { return RefreshTokenPage_1.RefreshTokenPage; } });
-var EmergencyLogoutPage_1 = require("./EmergencyLogoutPage");
-Object.defineProperty(exports, "EmergencyLogoutPage", { enumerable: true, get: function () { return EmergencyLogoutPage_1.EmergencyLogoutPage; } });
+// GUARDED wrappers only. Exporting the raw components from './TestEnvPage'
+// etc. would reintroduce an ungated path to the same pages under a different
+// import, which is the "opt-in gate nobody opts into" the ruling rejected.
+var guarded_1 = require("./guarded");
+Object.defineProperty(exports, "TestEnvPage", { enumerable: true, get: function () { return guarded_1.TestEnvPage; } });
+Object.defineProperty(exports, "default", { enumerable: true, get: function () { return guarded_1.TestEnvPage; } });
+Object.defineProperty(exports, "JwtInspectPage", { enumerable: true, get: function () { return guarded_1.JwtInspectPage; } });
+Object.defineProperty(exports, "RefreshTokenPage", { enumerable: true, get: function () { return guarded_1.RefreshTokenPage; } });
+Object.defineProperty(exports, "EmergencyLogoutPage", { enumerable: true, get: function () { return guarded_1.EmergencyLogoutPage; } });

package/dist/routes/auth/logout.js

@@ -40,10 +40,11 @@ async function POST(req) {
             });
         }
         const sessionId = session.session?.token;
-        // Delete session from store (this also removes the refresh token)
+        // Delete session from EVERY store — canonical + BA secondary (181922).
+        // Canonical-only deletion let the ba: record resurrect the session.
         if (sessionId) {
             try {
-                await (0, session_store_1.deleteSession)(sessionId);
+                await (0, session_store_1.deleteSessionEverywhere)(sessionId);
                 console.info('[LOGOUT_ROUTE] Session deleted from store');
             }
             catch (error) {

package/dist/routes/auth/refresh.js

@@ -17,15 +17,41 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.POST = POST;
 const refresh_1 = require("../../api-handlers/auth/refresh");
+/**
+ * Resolve the client id from environment variables.
+ *
+ * Was: `process.env.CLIENT_ID || process.env.NEXT_PUBLIC_IDP_CLIENT_ID || ''`
+ * That fallback to empty string made "we do not know the client" indistinguishable from
+ * "the client id is blank". Callers cannot tell absence from a known-empty value.
+ *
+ * Card 221076 / 223542: absence is now `null`, which is representable and still falsy,
+ * so existing `if (!clientId)` guards behave exactly as before.
+ * (Ported verbatim from qapert-nighthawk/221076, where this fix already existed;
+ * the qa/222363 line carried viability's half but never got refresh's.)
+ */
+function resolveClientId() {
+    const clientId = process.env.CLIENT_ID || process.env.NEXT_PUBLIC_IDP_CLIENT_ID;
+    if (clientId) {
+        return clientId;
+    }
+    return null;
+}
 // Configuration is read at runtime from environment.
 function getConfig() {
     const idpBaseUrl = process.env.IDP_URL;
     if (!idpBaseUrl) {
         throw new Error('[IDP_URL] FATAL: IDP_URL environment variable is REQUIRED.');
     }
+    const clientId = resolveClientId();
+    if (!clientId) {
+        // Card 221076 / 223542: absence must be detectable, not collapsed to a default.
+        console.warn('[REFRESH_ROUTE] No CLIENT_ID or NEXT_PUBLIC_IDP_CLIENT_ID configured. ' +
+            'Token refresh will be attempted, but the server cannot identify which client ' +
+            'initiated the request. This may fail if the IDP requires a client ID.');
+    }
     return {
         idpBaseUrl,
-        clientId: process.env.CLIENT_ID || process.env.NEXT_PUBLIC_IDP_CLIENT_ID || '',
+        clientId: clientId || 'payez_default_client', // Handler-safe fallback
         refreshEndpoint: process.env.REFRESH_ENDPOINT || '/api/ExternalAuth/refresh',
     };
 }

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

@@ -23,13 +23,22 @@ import { NextRequest, NextResponse } from 'next/server';
  */
 export declare function GET(req: NextRequest): Promise<NextResponse<{}>>;
 /**
- * POST /api/auth/session - Update session data
+ * POST /api/auth/session - Update session METADATA
  *
- * Allows updating session metadata (not tokens).
- * Token refresh should use the /api/auth/refresh endpoint.
+ * Updates session metadata only. This route holds no authority over authentication
+ * state: it cannot set the 2FA verdict and it cannot set tokens.
+ *
+ * Token refresh uses POST /api/auth/refresh. The 2FA verdict is written only by the
+ * server-side verification path that actually observed the factor.
  *
  * Body:
  * - metadata: object - Custom metadata to store in session
+ *
+ * Any of CALLER_ASSERTED_FIELDS present in the body is a 400. The docstring above used
+ * to promise "metadata (not tokens)" while the handler wrote idpAccessToken,
+ * idpRefreshToken AND mfaVerified - that false parenthetical is the ONLY caution a
+ * mounter reads, and it is how this route came to be mounted (318272). The promise is
+ * now enforced by the code rather than asserted by the comment.
  */
 export declare function POST(req: NextRequest): Promise<NextResponse<{
     error: string;

package/dist/routes/auth/session.js

@@ -51,6 +51,26 @@ async function GET(req) {
             roles: session?.roles,
             hasAccessToken: !!session?.idpAccessToken,
         });
+        // A Better Auth cookie is NOT authorization. The Redis session is the
+        // authoritative record of what this user is allowed to do; without it we
+        // have no roles and no IDP access token, so there is nothing to authorize
+        // against. Returning a populated user here produces the worst failure mode
+        // available: a client that renders as signed-in and is not.
+        //
+        // MUST return empty {} for the same reason as line 34 — useSession() treats
+        // ANY non-empty response object as "authenticated".
+        //
+        // NOTE: an MFA-pending session IS present in Redis (it just has
+        // mfaVerified=false), so this gate does not break /verify-code. Gating on a
+        // missing accessToken instead WOULD break it.
+        if (!session) {
+            console.error('[SESSION_ROUTE] Redis session MISS — refusing to report authenticated', {
+                userId: authSession.user?.id,
+                redisSessionId: redisSessionId ? redisSessionId.substring(0, 8) + '...' : 'MISSING',
+                reason: redisSessionId ? 'session expired or evicted' : 'no session token on auth session',
+            });
+            return server_1.NextResponse.json({});
+        }
         // Return session format with Redis data
         // useSession() expects: { user: {...}, expires: "..." }
         // We enrich with all session data from Redis
@@ -92,13 +112,61 @@ async function GET(req) {
     }
 }
 /**
- * POST /api/auth/session - Update session data
+ * The fields this route USED to accept from the request body and must never accept
+ * again. Cards 308833 (critical) / 312092 (remediation spec) / 318272 / 311425.
+ *
+ * `twoFactorComplete` was written straight through to `mfaVerified`, so a caller
+ * holding any session supplied its OWN second-factor verdict - no factor presented,
+ * no comparison against `amr`, no server-side derivation. The caller can be PRE-2FA,
+ * which makes this a 2FA bypass rather than a user rewriting a flag he had earned.
  *
- * Allows updating session metadata (not tokens).
- * Token refresh should use the /api/auth/refresh endpoint.
+ * The package already states the invariant in four places, in its own voice:
+ *   api-handlers/mfa/totp-verify.ts   - "Enrolment must never set mfaVerified."
+ *   api-handlers/auth/refresh.ts      - "mfaVerified is derived from amrClaims"
+ *   auth/better-auth.ts               - "computed fresh ... re-derived fresh"
+ *   (consumer) passkey-signin-plugin  - "mfaVerified is DERIVED from amr, never asserted."
+ * Every other writer in the estate derives it. This one route took it from an HTTP body.
+ *
+ * PRESENCE, NOT TRUTHINESS, is what is refused - `twoFactorComplete: false` is rejected
+ * exactly like `true`. A caller must not be able to drive this field in EITHER direction,
+ * and per R486/R908 an absent signal is "cannot determine", never a negative assertion.
+ *
+ * REFUSED LOUDLY RATHER THAN IGNORED SILENTLY. Dropping the field would leave a caller
+ * believing it had recorded a 2FA completion that never happened - the same failure shape
+ * as the 4.1.14 -> 4.1.31 history below, where a write nobody read looked like it worked.
+ *
+ * *** DO NOT "FIX" A REGRESSION HERE BY REVERTING THE KEY NORMALIZATION (312092 s2). ***
+ * 4.1.14 had this same unvalidated write but stored bare `accessToken`/`twoFactorComplete`,
+ * keys no reader consulted, so the forgery landed where nothing looked. The 4.1.31
+ * normalization did not introduce the bug - IT ARMED IT. Reverting re-hides the hole and
+ * restores two real client-facing bugs. The write is authorized here instead.
+ */
+const CALLER_ASSERTED_FIELDS = [
+    { field: 'twoFactorComplete', why: 'the second-factor verdict is derived from the IDP token (amr), never asserted by the caller' },
+    { field: 'mfaVerified', why: 'the second-factor verdict is derived from the IDP token (amr), never asserted by the caller' },
+    { field: 'twoFactorMethod', why: 'the method is recorded by the server-side verification path that observed the factor' },
+    { field: 'access_token', why: 'tokens are issued by the IDP; use POST /api/auth/refresh' },
+    { field: 'refresh_token', why: 'tokens are issued by the IDP; use POST /api/auth/refresh' },
+    { field: 'idpAccessToken', why: 'tokens are issued by the IDP; use POST /api/auth/refresh' },
+    { field: 'idpRefreshToken', why: 'tokens are issued by the IDP; use POST /api/auth/refresh' },
+];
+/**
+ * POST /api/auth/session - Update session METADATA
+ *
+ * Updates session metadata only. This route holds no authority over authentication
+ * state: it cannot set the 2FA verdict and it cannot set tokens.
+ *
+ * Token refresh uses POST /api/auth/refresh. The 2FA verdict is written only by the
+ * server-side verification path that actually observed the factor.
  *
  * Body:
  * - metadata: object - Custom metadata to store in session
+ *
+ * Any of CALLER_ASSERTED_FIELDS present in the body is a 400. The docstring above used
+ * to promise "metadata (not tokens)" while the handler wrote idpAccessToken,
+ * idpRefreshToken AND mfaVerified - that false parenthetical is the ONLY caution a
+ * mounter reads, and it is how this route came to be mounted (318272). The promise is
+ * now enforced by the code rather than asserted by the comment.
  */
 async function POST(req) {
     try {
@@ -117,7 +185,21 @@ async function POST(req) {
             }, { status: 400 });
         }
         const body = await req.json();
-        const { metadata, access_token, refresh_token, twoFactorComplete, twoFactorMethod } = body;
+        // Refuse before reading the session: a caller must not learn whether its forged
+        // field would have landed, and nothing should be written on a rejected request.
+        const asserted = CALLER_ASSERTED_FIELDS.filter(({ field }) => body != null && Object.prototype.hasOwnProperty.call(body, field));
+        if (asserted.length > 0) {
+            console.warn('[SESSION_ROUTE] REFUSED caller-asserted authentication state', {
+                fields: asserted.map(({ field }) => field),
+                userId: authSession.user?.id,
+            });
+            return server_1.NextResponse.json({
+                error: 'This route updates session metadata only. It cannot set authentication state.',
+                code: 'CALLER_ASSERTED_AUTH_STATE',
+                fields: asserted.map(({ field, why }) => ({ field, why })),
+            }, { status: 400 });
+        }
+        const { metadata } = body;
         // Get current session from Redis
         const session = await (0, session_store_1.getSession)(sessionToken);
         if (!session) {
@@ -126,13 +208,14 @@ async function POST(req) {
                 code: 'SESSION_NOT_FOUND'
             }, { status: 404 });
         }
-        // Update session with new data
+        // Update session with new data.
+        //
+        // METADATA ONLY. The token and 2FA-verdict writes that used to live here were
+        // removed, not merely guarded: see CALLER_ASSERTED_FIELDS above. Anything that
+        // needs to write authentication state must do so from a path that OBSERVED the
+        // fact - the IDP exchange for tokens, the verification path for the 2FA verdict.
         const updatedSession = {
             ...session,
-            ...(access_token ? { accessToken: access_token } : {}),
-            ...(refresh_token ? { refreshToken: refresh_token } : {}),
-            ...(typeof twoFactorComplete === 'boolean' ? { twoFactorComplete } : {}),
-            ...(twoFactorMethod ? { twoFactorMethod } : {}),
             ...(metadata ? {
                 metadata: {
                     ...(session.metadata || {}),

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

@@ -3,23 +3,53 @@
  *
  * Returns client auth settings for pre-login pages (signup, login).
  * Does NOT require authentication - these are public client settings.
+ *
+ * ── 257255: THIS ROUTE USED TO FABRICATE AN AUTHORIZATION POLICY ───────────
+ * It returned `success: true` with a hardcoded policy on ANY failure, so a
+ * caller could not distinguish "the IDP says X" from "I never reached the
+ * IDP". On 2026-08-24 it served require2FA=true / ["email","sms"] for hours
+ * while the database said require_2fa=false / ["emailcode","totp"] - wrong
+ * about WHETHER 2FA applied and WHICH factors existed, simultaneously and
+ * confidently. Six agents spent a night measuring policy with this instrument.
+ *
+ * Worse, the alarm it swallowed was CORRECT: idp-client-config throws
+ * specifically to stop an empty secret reaching betterAuth() and being
+ * silently replaced by the PUBLIC DEFAULT_SECRET. This route caught that and
+ * returned success.
+ *
+ * BAPert ruling v32: THE ENDPOINT HARD-FAILS, THE PAGE DEGRADES.
+ * QAPert's decisive measurement: the SAME client is require_2fa=TRUE on AKS
+ * and FALSE on dev-93, so ANY hardcoded fallback is provably wrong in one
+ * environment by construction. There is no safe default because the value is
+ * per-client per-environment DATA.
+ *
+ * The positive control already existed in this package: /api/session/viability
+ * surfaces this same fault honestly. These two routes now agree.
  */
 import { NextResponse } from 'next/server';
 export interface PublicAuthSettings {
     enabledProviders: string[];
-    allowPublicRegistration: boolean;
     allowFederatedLogin: boolean;
-    enablePasswordReset: boolean;
     require2FA: boolean;
     allowed2FAMethods: string[];
+    allowPublicRegistration?: boolean;
+    enablePasswordReset?: boolean;
 }
+/** Stable, machine-readable failure codes. Consumers branch on these. */
+export type AuthSettingsErrorCode = 'IDP_UNREACHABLE' | 'IDP_CONFIG_INVALID';
 /**
  * GET /api/auth/settings
  *
- * Returns public auth settings for the current client.
- * Used by login/signup pages to determine what options to show.
+ * Returns public auth settings for the current client, or 503 if the real
+ * policy could not be read. It never answers from a default.
  */
 export declare function GET(): Promise<NextResponse<{
+    success: boolean;
+    error: {
+        code: AuthSettingsErrorCode;
+        message: string;
+    };
+}> | NextResponse<{
     success: boolean;
     data: PublicAuthSettings;
 }>>;

package/dist/routes/auth/settings.js

@@ -4,52 +4,106 @@
  *
  * Returns client auth settings for pre-login pages (signup, login).
  * Does NOT require authentication - these are public client settings.
+ *
+ * ── 257255: THIS ROUTE USED TO FABRICATE AN AUTHORIZATION POLICY ───────────
+ * It returned `success: true` with a hardcoded policy on ANY failure, so a
+ * caller could not distinguish "the IDP says X" from "I never reached the
+ * IDP". On 2026-08-24 it served require2FA=true / ["email","sms"] for hours
+ * while the database said require_2fa=false / ["emailcode","totp"] - wrong
+ * about WHETHER 2FA applied and WHICH factors existed, simultaneously and
+ * confidently. Six agents spent a night measuring policy with this instrument.
+ *
+ * Worse, the alarm it swallowed was CORRECT: idp-client-config throws
+ * specifically to stop an empty secret reaching betterAuth() and being
+ * silently replaced by the PUBLIC DEFAULT_SECRET. This route caught that and
+ * returned success.
+ *
+ * BAPert ruling v32: THE ENDPOINT HARD-FAILS, THE PAGE DEGRADES.
+ * QAPert's decisive measurement: the SAME client is require_2fa=TRUE on AKS
+ * and FALSE on dev-93, so ANY hardcoded fallback is provably wrong in one
+ * environment by construction. There is no safe default because the value is
+ * per-client per-environment DATA.
+ *
+ * The positive control already existed in this package: /api/session/viability
+ * surfaces this same fault honestly. These two routes now agree.
  */
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.GET = GET;
 const server_1 = require("next/server");
 const idp_client_config_1 = require("../../lib/idp-client-config");
+/**
+ * Fail closed and LOUD. 503 + success:false + a code, and CRUCIALLY no policy
+ * fields at all - not defaults, not partials. A consumer cannot mistake an
+ * absent body for an answer, which is exactly the mistake the old shape invited.
+ */
+function policyUnavailable(code, message) {
+    return server_1.NextResponse.json({ success: false, error: { code, message } }, { status: 503, headers: { 'Cache-Control': 'no-store' } });
+}
 /**
  * GET /api/auth/settings
  *
- * Returns public auth settings for the current client.
- * Used by login/signup pages to determine what options to show.
+ * Returns public auth settings for the current client, or 503 if the real
+ * policy could not be read. It never answers from a default.
  */
 async function GET() {
+    let config;
     try {
-        const config = await (0, idp_client_config_1.getIDPClientConfig)();
-        const settings = {
-            // Get enabled OAuth provider names
-            enabledProviders: config.oauthProviders
-                ?.filter(p => p.enabled)
-                .map(p => p.provider) ?? [],
-            // Registration - default to true if not specified
-            allowPublicRegistration: true, // Could come from config.authSettings in future
-            allowFederatedLogin: config.oauthProviders?.some(p => p.enabled) ?? false,
-            // Password reset
-            enablePasswordReset: true, // Could come from config.authSettings in future
-            // 2FA
-            require2FA: config.authSettings?.require2FA ?? true,
-            allowed2FAMethods: config.authSettings?.allowed2FAMethods ?? ['email', 'sms'],
-        };
-        return server_1.NextResponse.json({
-            success: true,
-            data: settings,
-        });
+        config = await (0, idp_client_config_1.getIDPClientConfig)();
     }
     catch (error) {
+        // Keep the loud line - it is what finally unmasked this in production.
         console.error('[AUTH_SETTINGS] Failed to get settings:', error);
-        // Return safe defaults on error
-        return server_1.NextResponse.json({
-            success: true,
-            data: {
-                enabledProviders: [],
-                allowPublicRegistration: true,
-                allowFederatedLogin: false,
-                enablePasswordReset: true,
-                require2FA: true,
-                allowed2FAMethods: ['email', 'sms'],
-            },
-        });
+        // The `degraded: true` shape that used to live here (240447) is gone
+        // deliberately. It still answered `success: true` with a full invented
+        // policy and merely LABELLED the guess - which BAPert v32 rules out:
+        // THE ENDPOINT HARD-FAILS, THE PAGE DEGRADES. A flag a consumer may
+        // ignore is not a failure; 503 with no policy fields is.
+        return policyUnavailable('IDP_UNREACHABLE', 'Could not read client configuration from the identity service.');
+    }
+    // ── THE CONDITION IS "DID I READ A VALIDATED POLICY", NOT "DID THE FETCH
+    //    THROW". This distinction is load-bearing and is why the catch above is
+    //    not sufficient on its own (QAPert, and card 257661).
+    //
+    //    getIDPClientConfig caches BEFORE it validates, and the cache-hit paths
+    //    do NOT re-validate. So it can RETURN NORMALLY - no throw, no log line -
+    //    with a config that FAILED validation on the request that cached it.
+    //    Measured on :4702 on 2026-08-24: the loader was throwing 53 times per
+    //    400 log lines while THIS endpoint served a well-formed policy from
+    //    cache. A fix that only handles the throw is bypassed by the cache on
+    //    every request after the first.
+    //
+    //    authSecret is the invariant the loader itself enforces on the fetch
+    //    path (idp-client-config: "LOAD-BEARING - empty must fail here, never
+    //    downstream"). Re-checking it here is what makes a cache hit as safe as
+    //    a fresh read.
+    if (!config?.authSecret) {
+        console.error('[AUTH_SETTINGS] Refusing to serve policy: config has no authSecret ' +
+            '(likely served from cache before validation - see card 257661).');
+        return policyUnavailable('IDP_CONFIG_INVALID', 'Client configuration is incomplete; refusing to report a policy.');
+    }
+    // No `??` defaults. If the policy section is absent or malformed we did not
+    // read a policy, and inventing one is the defect this card exists for.
+    const authSettings = config.authSettings;
+    if (!authSettings ||
+        typeof authSettings.require2FA !== 'boolean' ||
+        !Array.isArray(authSettings.allowed2FAMethods)) {
+        console.error('[AUTH_SETTINGS] Refusing to serve policy: authSettings absent or malformed.');
+        return policyUnavailable('IDP_CONFIG_INVALID', 'Client configuration carried no usable auth policy.');
     }
+    const settings = {
+        enabledProviders: config.oauthProviders?.filter(p => p.enabled).map(p => p.provider) ?? [],
+        // Prefer the EXPLICIT policy field over inferring from the provider
+        // list (240447). Inferring is only a proxy: a tenant can have federated
+        // login switched off while enabled providers are still configured, and
+        // the inference reports `true` for it. Fall back to the inference only
+        // where the IDP does not state the field.
+        allowFederatedLogin: authSettings.allowSocialLogin ??
+            (config.oauthProviders?.some(p => p.enabled) ?? false),
+        // Real reads, no `??` literal. Absent stays absent (see interface).
+        allowPublicRegistration: authSettings.allowPublicRegistration,
+        enablePasswordReset: authSettings.enablePasswordReset,
+        require2FA: authSettings.require2FA,
+        allowed2FAMethods: authSettings.allowed2FAMethods,
+    };
+    return server_1.NextResponse.json({ success: true, data: settings }, { headers: { 'Cache-Control': 'no-store' } });
 }

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

@@ -44,7 +44,7 @@ export declare function GET(req: NextRequest): Promise<NextResponse<{
     accessTokenExpired: boolean;
     expiresAt: string;
     roles: string[];
-    clientId: string;
+    clientId: string | null;
 }> | NextResponse<{
     viable: boolean;
     needsRefresh: boolean;