@payez/next-mvp 4.1.20 → 4.4.0

package/src/routes/auth/session.ts

@@ -55,6 +55,27 @@ export async function GET(req: NextRequest) {
       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 NextResponse.json({});
+    }
+
     // Return session format with Redis data
     // useSession() expects: { user: {...}, expires: "..." }
     // We enrich with all session data from Redis
@@ -96,13 +117,62 @@ export async function GET(req: NextRequest) {
 }
 
 /**
- * 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: ReadonlyArray<{ field: string; why: string }> = [
+  { 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.
  */
 export async function POST(req: NextRequest) {
   try {
@@ -124,7 +194,25 @@ export async function POST(req: NextRequest) {
     }
 
     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 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 getRedisSession(sessionToken);
@@ -135,13 +223,14 @@ export async function POST(req: NextRequest) {
       }, { 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/src/routes/auth/settings.ts

@@ -3,6 +3,28 @@
  *
  * 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';
@@ -11,65 +33,145 @@ import { getIDPClientConfig } from '../../lib/idp-client-config';
 export interface PublicAuthSettings {
     // OAuth providers enabled for this client
     enabledProviders: string[];
-
-    // Registration settings
-    allowPublicRegistration: boolean;
     allowFederatedLogin: boolean;
 
-    // Password settings
-    enablePasswordReset: boolean;
-
     // 2FA settings (public - no secrets)
     require2FA: boolean;
     allowed2FAMethods: string[];
+
+    // allowPublicRegistration / enablePasswordReset: OPTIONAL, never invented.
+    //
+    // 257255 removed these outright on the measurement that AuthSettings
+    // "carries no such fields, so they cannot be read today", and left one
+    // instruction: "Re-add them ONLY when the config document actually carries
+    // them." That precondition is now MET. The 240447 fix landed on master
+    // after 257255 was written and taught the loader to read them - AuthSettings
+    // now declares allowPublicRegistration?/enablePasswordReset? and
+    // idp-client-config maps them from auth_settings.allow_public_registration /
+    // enable_password_reset at BOTH construction sites. Re-adding them here is
+    // that instruction being followed, not overridden: deleting them now would
+    // discard a real measurement the loader already performs.
+    //
+    // They are OPTIONAL rather than defaulted, which is the part 240447 got
+    // wrong. Its `?? true` was defended as "preserves today's behaviour ...
+    // cannot regress an older IDP build", but `true` is a PERMISSION CLAIM about
+    // a tenant we did not successfully ask - the same defect class this card
+    // exists to kill, and the exact literal named in its title
+    // (allowPublicRegistration:TRUE). Absent means the IDP did not say; a
+    // consumer must then decide, and cannot mistake a guess for a policy.
+    //
+    // They are NOT validated into a hard 503 like require2FA below, because an
+    // older IDP build may legitimately omit them. Absent-and-honest is correct
+    // there; absent-and-fabricated is not.
+    allowPublicRegistration?: boolean;
+    enablePasswordReset?: boolean;
+}
+
+/** Stable, machine-readable failure codes. Consumers branch on these. */
+export type AuthSettingsErrorCode = 'IDP_UNREACHABLE' | 'IDP_CONFIG_INVALID';
+
+/**
+ * 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: AuthSettingsErrorCode, message: string) {
+    return 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.
  */
 export async function GET() {
+    let config;
     try {
-        const config = await getIDPClientConfig();
+        config = await getIDPClientConfig();
+    } catch (error) {
+        // Keep the loud line - it is what finally unmasked this in production.
+        console.error('[AUTH_SETTINGS] Failed to get settings:', error);
+        // 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.',
+        );
+    }
 
-        const settings: PublicAuthSettings = {
-            // Get enabled OAuth provider names
-            enabledProviders: config.oauthProviders
-                ?.filter(p => p.enabled)
-                .map(p => p.provider) ?? [],
+    // 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.',
+        );
+    }
 
-            // Registration - default to true if not specified
-            allowPublicRegistration: true, // Could come from config.authSettings in future
-            allowFederatedLogin: config.oauthProviders?.some(p => p.enabled) ?? false,
+    const settings: PublicAuthSettings = {
+        enabledProviders: config.oauthProviders?.filter(p => p.enabled).map(p => p.provider) ?? [],
 
-            // Password reset
-            enablePasswordReset: true, // Could come from config.authSettings in future
+        // 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),
 
-            // 2FA
-            require2FA: config.authSettings?.require2FA ?? true,
-            allowed2FAMethods: config.authSettings?.allowed2FAMethods ?? ['email', 'sms'],
-        };
+        // Real reads, no `??` literal. Absent stays absent (see interface).
+        allowPublicRegistration: authSettings.allowPublicRegistration,
+        enablePasswordReset: authSettings.enablePasswordReset,
 
-        return NextResponse.json({
-            success: true,
-            data: settings,
-        });
-    } catch (error) {
-        console.error('[AUTH_SETTINGS] Failed to get settings:', error);
+        require2FA: authSettings.require2FA,
+        allowed2FAMethods: authSettings.allowed2FAMethods,
+    };
 
-        // Return safe defaults on error
-        return NextResponse.json({
-            success: true,
-            data: {
-                enabledProviders: [],
-                allowPublicRegistration: true,
-                allowFederatedLogin: false,
-                enablePasswordReset: true,
-                require2FA: true,
-                allowed2FAMethods: ['email', 'sms'],
-            } as PublicAuthSettings,
-        });
-    }
+    return NextResponse.json(
+        { success: true, data: settings },
+        { headers: { 'Cache-Control': 'no-store' } },
+    );
 }

package/src/routes/auth/viability.ts

@@ -74,21 +74,61 @@ async function getTenantRequiresTwoFactor(): Promise<boolean> {
  * nullable require_2fa fix: "absent" has to be expressible, or callers cannot
  * tell a real value from a default.
  *
- * No local default: `allowed2FAMethods` is non-optional on AuthSettings and is
- * populated on BOTH config construction paths (idp-client-config.ts:333, :514)
- * with the tenant's value or the layer's own ['email','sms']. Repeating that
- * default here would be a second source for one setting, free to drift.
+ * No local default. 257255 UPDATE: allowed2FAMethods is now OPTIONAL on
+ * AuthSettings - the config mapper no longer substitutes ['email','sms'] when
+ * the document carries no policy, because that made "no policy" and "exactly
+ * these methods" indistinguishable. So absent now correctly reaches this
+ * function as undefined and is reported as UNKNOWN (null), which is what this
+ * function's own contract already said it wanted. Before the change it would
+ * have returned the mapper's fabrication AS IF IT WERE THE TENANT'S VALUE.
  */
 async function getTenantAllowed2FAMethods(): Promise<string[] | null> {
   try {
     const config = await getIDPClientConfig();
-    return config.authSettings.allowed2FAMethods;
+    // `?? null` is the whole point: undefined means the document carried no
+    // policy, and this function reports UNKNOWN rather than guessing.
+    return config.authSettings.allowed2FAMethods ?? null;
   } catch {
     console.warn('[VIABILITY] Could not get client config — reporting allowed 2FA methods as UNKNOWN (null), not guessing');
     return null;
   }
 }
 
+/**
+ * Resolve the client id reported to the caller.
+ *
+ * Was: `session?.idpClientId || process.env.IDP_CLIENT_ID || ''`. Two defects,
+ * both of the "report a confident value where the truth is unknown" family that
+ * card 221076 was about:
+ *
+ * 1. `|| ''` made "we do not know this session's client" indistinguishable from
+ *    "the client id is blank". Callers cannot tell absence from a known-empty
+ *    value, so nothing can react to the former. Absence is now `null`, which is
+ *    representable — and still falsy, so existing `if (!clientId)` guards behave
+ *    exactly as before.
+ *
+ * 2. The env fallback SILENTLY substitutes the deployment's default client for a
+ *    session whose own client is unknown. On a multi-tenant IDP that is a
+ *    cross-tenant wrong answer, not a default. It is kept for single-tenant
+ *    deployments that rely on it, but it now says so in the log rather than
+ *    passing the substitution off as the session's own identity.
+ */
+function resolveClientId(sessionClientId: string | undefined): string | null {
+  if (sessionClientId) return sessionClientId;
+
+  const envClientId = process.env.IDP_CLIENT_ID;
+  if (envClientId) {
+    console.warn(
+      '[VIABILITY_ROUTE] session carries no idpClientId - substituting IDP_CLIENT_ID ' +
+        'from the environment. On a multi-tenant deployment this is a DIFFERENT client ' +
+        'than the session belongs to.'
+    );
+    return envClientId;
+  }
+
+  return null;
+}
+
 /**
  * GET /api/session/viability - Check if session is viable
  *
@@ -165,9 +205,87 @@ export async function GET(req: NextRequest) {
     // require_2fa case: absent has to stay expressible.
     const nextStep = session?.nextStep;
 
+    /**
+     * 266007 — port the sibling's CRITICAL override (api-handlers/session/
+     * viability.ts:82-86) into this, the impl consumers actually MOUNT.
+     * An OAuth session whose callback set mfaVerified === false because no
+     * refresh_token was issued ALWAYS needs 2FA completion, whatever the
+     * tenant config says — completing 2FA is how it obtains one.
+     *
+     * STRICT === false, deliberately: an ABSENT mfaVerified (every session
+     * minted before that field existed) is not a signal, and treating it as
+     * one would force-rechallenge the entire existing session population.
+     *
+     * *** R807 (BAPert, card 362550) - WHY THE `=== false` TEST ALONE NO LONGER
+     * CARRIES THAT INTENT, AND WHAT RESTORES IT. ***
+     *
+     * The intent above is right, but by the time a session reaches here the
+     * distinction it depends on IS ALREADY GONE: every construction site
+     * (session-store, decode-session, token-lifecycle x2, SessionModel) collapses
+     * an absent mfaVerified to `false` via `?? false`. So `=== false` had stopped
+     * meaning "the callback affirmatively said false" and had come to mean
+     * "affirmatively false OR never knew" - i.e. the exact mass re-challenge this
+     * comment says it is preventing. The guard read as strict while behaving as
+     * permissive, because the collapse happens upstream and out of sight.
+     *
+     * R807 keeps `mfaVerified` fail-closed at all five sites (removing `?? false`
+     * would be an AUTH BYPASS - a session that never proved MFA read as having
+     * proved it) and gives THIS question its own signal instead. So the test is
+     * now two parts:
+     *
+     *   mfaSignalPresent === true  -> the producer really did emit a value, so the
+     *                                 `false` below is a MEASUREMENT. Fire.
+     *   absent / false             -> LEGACY session (minted before the signal
+     *                                 existed) or a path with no IDP tokens at all.
+     *                                 NOT a signal. Do NOT force a re-challenge.
+     *
+     * That absent-means-do-not-fire read is the migration behaviour, and it is
+     * what preserves this comment's original guarantee verbatim through rollout:
+     * on the day this ships, EVERY existing session has no signal and none of them
+     * is re-challenged.
+     *
+     * *** AND IT IS SAFE ONLY BECAUSE IT IS CONFINED HERE. *** mfaSignalPresent is
+     * permissive by construction - it can only ever SUPPRESS this override. It must
+     * never reach a path that grants access; gate those on `mfaVerified`, which is
+     * still fail-closed everywhere. R807 is void if this signal escapes into an
+     * auth decision.
+     *
+     * Declared once here, like nextStep above, so the three authenticated
+     * responses cannot drift apart. Feeds the legacy `requires2FA` field the
+     * middleware actually gates on; `tenantRequiresTwoFactor` stays pure —
+     * it names TENANT policy, and this override is not tenant state.
+     */
+    const oauthSessionNeedsTwoFactor =
+      session?.mfaSignalPresent === true &&
+      session?.mfaVerified === false &&
+      !(session.idpRefreshToken || (session as any)?.refreshToken);
+
     // Check access token expiry
     const now = Math.floor(Date.now() / 1000);
-    const accessTokenExpires = (token as any).accessTokenExpires || token.exp;
+    // 240654 addendum 2: fall back to the Redis session's own expiry.
+    //
+    // The first two reads come off the Better Auth session OBJECT. A Path-B
+    // synthetic session — the shape server/auth.ts builds for a legacy JWS
+    // session — carries NEITHER: it is `{session:{token}, user:{...}}` with no
+    // accessTokenExpires and no exp. So every legacy session fell into the
+    // "no expiry info" branch below and answered needsRefresh:true on EVERY
+    // viability read from the moment of login, while the token was in fact
+    // fresh (15-minute TTL measured). Benign for the viable/authenticated
+    // verdict, but it recommends a refresh constantly, which is pure perf
+    // noise and multiplies exposure to the empty-clientId refresh path (223542).
+    //
+    // lib/session-store puts the real value on the session as
+    // idpAccessTokenExpires, in MILLISECONDS (better-auth.ts:784 sets
+    // `Date.now() + expires_in * 1000`). The other two sources are in SECONDS.
+    // Mixing units here would be a silent disaster, so note that the
+    // normalisation below (`> 1e12 ? /1000 : as-is`) already discriminates
+    // them by magnitude: a seconds timestamp is ~1.7e9, a milliseconds one
+    // ~1.7e12. This fallback is therefore safe in either unit, and that
+    // existing normaliser is load-bearing for it -- do not remove it.
+    const accessTokenExpires =
+      (token as any).accessTokenExpires ||
+      token.exp ||
+      (session as any)?.idpAccessTokenExpires;
 
     if (!accessTokenExpires) {
       // No expiry info, assume viable but recommend refresh
@@ -199,7 +317,7 @@ export async function GET(req: NextRequest) {
         tenantAllowed2FAMethods,
         nextStep,
         // Legacy field names for backwards compatibility
-        requires2FA: tenantRequiresTwoFactor,
+        requires2FA: tenantRequiresTwoFactor || oauthSessionNeedsTwoFactor,
         twoFactorComplete: userHasCompletedTenantTwoFactorRequirements,
         accessTokenExpired: false,
         reason: 'No expiry information'
@@ -269,13 +387,13 @@ export async function GET(req: NextRequest) {
         tenantAllowed2FAMethods,
         nextStep,
         // Legacy names for backwards compatibility
-        requires2FA: tenantRequiresTwoFactor,
+        requires2FA: tenantRequiresTwoFactor || oauthSessionNeedsTwoFactor,
         twoFactorComplete: userHasCompletedTenantTwoFactorRequirements,
         accessTokenExpired: true,
         reason: 'Token expired',
         // RBAC fields
         roles: session?.roles || [],
-        clientId: session?.idpClientId || process.env.IDP_CLIENT_ID || '',
+        clientId: resolveClientId(session?.idpClientId),
       });
     }
 
@@ -293,13 +411,13 @@ export async function GET(req: NextRequest) {
       tenantAllowed2FAMethods,
       nextStep,
       // Legacy names for backwards compatibility
-      requires2FA: tenantRequiresTwoFactor,
+      requires2FA: tenantRequiresTwoFactor || oauthSessionNeedsTwoFactor,
       twoFactorComplete: userHasCompletedTenantTwoFactorRequirements,
       accessTokenExpired: false,
       expiresAt: new Date(expiryTime * 1000).toISOString(),
       // RBAC fields
       roles: session?.roles || [],
-      clientId: session?.idpClientId || process.env.IDP_CLIENT_ID || '',
+      clientId: resolveClientId(session?.idpClientId),
     });
   } catch (error) {
     console.error('[VIABILITY_ROUTE] Error checking session viability:', error);

package/src/routes/mfa/backup-code-verify.ts

@@ -1 +1 @@
-export { POST } from '../../api-handlers/mfa/backup-code-verify';
+export { POST } from '../../api-handlers/mfa/backup-code-verify';

package/src/routes/mfa/backup-codes.ts

@@ -1,10 +1,10 @@
-/**
- * Ready-to-Use MFA Backup Codes Route
- *
- * @example
- * ```typescript
- * // app/api/mfa/backup-codes/route.ts
- * export { POST } from '@payez/next-mvp/routes/mfa/backup-codes';
- * ```
- */
-export { POST } from '../../api-handlers/mfa/backup-codes';
+/**
+ * Ready-to-Use MFA Backup Codes Route
+ *
+ * @example
+ * ```typescript
+ * // app/api/mfa/backup-codes/route.ts
+ * export { POST } from '@payez/next-mvp/routes/mfa/backup-codes';
+ * ```
+ */
+export { POST } from '../../api-handlers/mfa/backup-codes';

package/src/routes/mfa/methods.ts

@@ -1,22 +1,22 @@
-/**
- * Ready-to-Use MFA Methods Route (list / remove)
- *
- * @example
- * ```typescript
- * // app/api/mfa/methods/route.ts
- * export { GET } from '@payez/next-mvp/routes/mfa/methods';
- * // app/api/mfa/methods/[id]/route.ts
- * export { DELETE } from '@payez/next-mvp/routes/mfa/methods';
- * ```
- */
-import { NextRequest } from 'next/server';
-import { GET as listMethods, DELETE as deleteMethod } from '../../api-handlers/mfa/methods';
-
-export const GET = listMethods;
-
-type Ctx = { params: Promise<{ id: string }> };
-
-export async function DELETE(req: NextRequest, ctx: Ctx) {
-  const { id } = await ctx.params;
-  return deleteMethod(req, id);
-}
+/**
+ * Ready-to-Use MFA Methods Route (list / remove)
+ *
+ * @example
+ * ```typescript
+ * // app/api/mfa/methods/route.ts
+ * export { GET } from '@payez/next-mvp/routes/mfa/methods';
+ * // app/api/mfa/methods/[id]/route.ts
+ * export { DELETE } from '@payez/next-mvp/routes/mfa/methods';
+ * ```
+ */
+import { NextRequest } from 'next/server';
+import { GET as listMethods, DELETE as deleteMethod } from '../../api-handlers/mfa/methods';
+
+export const GET = listMethods;
+
+type Ctx = { params: Promise<{ id: string }> };
+
+export async function DELETE(req: NextRequest, ctx: Ctx) {
+  const { id } = await ctx.params;
+  return deleteMethod(req, id);
+}

package/src/routes/mfa/totp-confirm.ts

@@ -1,10 +1,10 @@
-/**
- * Ready-to-Use TOTP Confirm Route
- *
- * @example
- * ```typescript
- * // app/api/mfa/totp/confirm/route.ts
- * export { POST } from '@payez/next-mvp/routes/mfa/totp-confirm';
- * ```
- */
-export { POST } from '../../api-handlers/mfa/totp-confirm';
+/**
+ * Ready-to-Use TOTP Confirm Route
+ *
+ * @example
+ * ```typescript
+ * // app/api/mfa/totp/confirm/route.ts
+ * export { POST } from '@payez/next-mvp/routes/mfa/totp-confirm';
+ * ```
+ */
+export { POST } from '../../api-handlers/mfa/totp-confirm';