@payez/next-mvp 4.4.3 → 4.4.4

package/dist/api/auth-handler.js

@@ -17,7 +17,6 @@ Object.defineProperty(exports, "__esModule", { value: true });
 exports.createAuthHandler = createAuthHandler;
 const server_1 = require("next/server");
 const auth_1 = require("../server/auth");
-const acr_1 = require("../lib/acr");
 const nanoid_1 = require("nanoid");
 const session_store_1 = require("../lib/session-store");
 /**
@@ -159,18 +158,10 @@ function createAuthHandler(options = {}) {
                 console.error('[AUTH_HANDLER] No refresh token available');
                 return { success: false, error: 'No refresh token' };
             }
-            // Extract authentication methods from session.
-            //
-            // 375639: these two lines used to read
-            //     authMethods = ... : ['pwd', 'mfa']
-            //     authLevel   = String(... || ... || '2')
-            // so a session that knew NOTHING about how the user authenticated told
-            // the IDP that a second factor had happened AND named 'mfa' as the
-            // method. The two fabrications corroborated each other, so a downstream
-            // check cross-validating amr against acr would have accepted the pair.
-            // Absent is not satisfied; both now resolve fail-closed, in one place.
-            const authMethods = (0, acr_1.resolveAuthMethods)(currentSession.authMethods, currentSession.token?.amr);
-            const authLevel = (0, acr_1.resolveAcrLevel)(currentSession.authenticationLevel, currentSession.token?.acr);
+            // Extract authentication methods from session
+            const authMethods = currentSession.authMethods ||
+                (currentSession.token?.amr ? JSON.parse(currentSession.token.amr) : ['pwd', 'mfa']);
+            const authLevel = String(currentSession.authenticationLevel || currentSession.token?.acr || '2');
             const twoFactorMethod = currentSession.twoFactorMethod || 'authenticator';
             // Build refresh request body
             const refreshRequestBody = {

package/dist/auth/better-auth.js

@@ -147,6 +147,20 @@ function isPlainObject(value) {
  * globalThis is per-process and per-runtime, which is exactly the lifetime a request-scoped
  * carrier needs to be reachable from every copy that might run inside the request.
  */
+/**
+ * THE KEY STAYS '__payezIdTokenScope' EVEN THOUGH THE SCOPE NOW CARRIES TWO
+ * THINGS. Renaming it would give a copy on the old name and a copy on the new
+ * name two DIFFERENT stores in the same process — which is precisely the
+ * double-load failure documented above, reintroduced by a cosmetic rename. The
+ * name is a wire contract between copies, not a description.
+ *
+ * accessToken is here for providers that do NOT issue an id_token. GitHub is
+ * not an OIDC provider: it has no id_token, no JWKS and no discovery document,
+ * so `id_token` can never be the field that proves a GitHub identity. The IDP
+ * re-derives that identity by calling GitHub itself with this access token
+ * (GitHubIdentityVerifier), which keeps the same rule google follows — the IDP
+ * verifies for itself and never trusts an asserted email.
+ */
 const ID_TOKEN_SCOPE_KEY = '__payezIdTokenScope';
 const gScope = globalThis;
 gScope[ID_TOKEN_SCOPE_KEY] ??= new node_async_hooks_1.AsyncLocalStorage();
@@ -248,9 +262,21 @@ function buildBetterAuthProviders(config) {
          * remains, so the provider emits exactly its default set.
          */
         const GOOGLE_DEFAULT_SCOPES = ['email', 'profile', 'openid'];
+        /**
+         * Same defect, same fix, different provider: github's createAuthorizationURL
+         * also seeds ['read:user','user:email'] unconditionally and then pushes ours
+         * on top (@better-auth/core social-providers/github.ts), so the stored row
+         * "read:user user:email" reached GitHub as
+         * "read:user user:email read:user user:email". Measured on :4799, not
+         * assumed. GitHub dedupes, so this is legibility rather than function — but
+         * a scope list is the first thing a security reviewer reads off that URL.
+         */
+        const GITHUB_DEFAULT_SCOPES = ['read:user', 'user:email'];
         const wireScopes = name === 'google'
             ? scopes.filter((s) => !GOOGLE_DEFAULT_SCOPES.includes(s))
-            : scopes;
+            : name === 'github'
+                ? scopes.filter((s) => !GITHUB_DEFAULT_SCOPES.includes(s))
+                : scopes;
         providers[name] = {
             clientId: oauth.clientId,
             clientSecret: oauth.clientSecret,
@@ -351,6 +377,82 @@ function buildBetterAuthProviders(config) {
                 };
             };
         }
+        /**
+         * GITHUB: THE SAME CAPTURE, A DIFFERENT TOKEN.
+         *
+         * GitHub is not an OIDC provider — it issues no id_token — so the google
+         * branch above can never fire for it and the exchange would post an
+         * assertion with nothing that proves identity. That is exactly the
+         * 401 UNVERIFIED_ASSERTION measured on :4799, whose diagnostics read
+         * `id_token_forwarded: false, id_token_length: 0` with `response_time_ms: 0`:
+         * the IDP rejected it instantly, without ever calling GitHub.
+         *
+         * getUserInfo is the ONLY provider hook that receives the token set (see the
+         * google note above), and @better-auth/core's github provider calls
+         * `options.getUserInfo(token)` BEFORE its own body — so installing this
+         * REPLACES the default rather than wrapping it, and the default's work has
+         * to be reproduced here or the sign-in loses its profile entirely.
+         *
+         * Mirrored verbatim from @better-auth/core/src/social-providers/github.ts at
+         * the version the container actually runs (better-auth 1.5.6 — the graft's
+         * node_modules says 1.6.29 and is NOT what executes). Kept deliberately
+         * dumb: it must not "improve" on upstream, because every divergence here is
+         * a behaviour change disguised as a token capture.
+         *
+         * This is NOT the identity check. The IDP re-derives the GitHub identity
+         * itself from this access token and enforces primary && verified server-side
+         * (GitHubIdentityVerifier); what we return here only shapes the local
+         * better-auth user record.
+         */
+        if (name === 'github') {
+            providers[name].getUserInfo = async (token) => {
+                const store = idTokenScope.getStore();
+                if (store) {
+                    store.accessToken = token?.accessToken;
+                }
+                else {
+                    console.warn('[BETTER_AUTH] github access_token captured but NO REQUEST SCOPE to put it in — ' +
+                        'it will NOT be forwarded and the IDP exchange will fail UNVERIFIED_ASSERTION. ' +
+                        'Check that GET is createAuthGetHandler(), not routes/auth/nextauth.');
+                }
+                const ghHeaders = {
+                    'User-Agent': 'better-auth',
+                    Authorization: `Bearer ${token?.accessToken}`,
+                };
+                const profileRes = await fetch('https://api.github.com/user', {
+                    headers: ghHeaders,
+                });
+                // Upstream returns null on profile error, which fails the sign-in
+                // closed. Preserved rather than softened.
+                if (!profileRes.ok) {
+                    console.warn(`[BETTER_AUTH] github getUserInfo: /user returned ${profileRes.status}`);
+                    return null;
+                }
+                const profile = (await profileRes.json());
+                const emailsRes = await fetch('https://api.github.com/user/emails', {
+                    headers: ghHeaders,
+                });
+                const emails = emailsRes.ok
+                    ? (await emailsRes.json())
+                    : undefined;
+                // A GitHub account with a private email returns profile.email = null;
+                // upstream falls back to the primary address here.
+                if (!profile.email && emails) {
+                    profile.email = (emails.find((e) => e.primary) ?? emails[0])?.email;
+                }
+                const emailVerified = emails?.find((e) => e.email === profile.email)?.verified ?? false;
+                return {
+                    user: {
+                        id: profile.id,
+                        name: profile.name || profile.login || '',
+                        email: profile.email,
+                        image: profile.avatar_url,
+                        emailVerified,
+                    },
+                    data: profile,
+                };
+            };
+        }
     }
     return providers;
 }
@@ -802,6 +904,21 @@ async function exchangeOAuthForIdpTokens(sessionToken, provider = 'google') {
                  * distinguishable from "the provider issued none".
                  */
                 ...(idTokenScope.getStore()?.idToken ? { id_token: idTokenScope.getStore().idToken } : {}),
+                /**
+                 * The same field for providers that have no id_token to give.
+                 *
+                 * Identical doctrine to the id_token above: RAW, forwarded verbatim,
+                 * NOTHING DERIVED FROM IT, and omitted entirely rather than sent null so
+                 * "never captured" stays distinguishable from "provider issued none".
+                 * The IDP verifies for itself by calling GitHub with this token and
+                 * enforcing primary && verified; we assert nothing about the identity.
+                 *
+                 * Scoped to the provider access token captured during THIS callback, so
+                 * a google login continues to send id_token only and is unaffected.
+                 */
+                ...(idTokenScope.getStore()?.accessToken
+                    ? { access_token: idTokenScope.getStore().accessToken }
+                    : {}),
             }),
         });
         const oauthResText = await oauthRes.text();
@@ -833,9 +950,21 @@ async function exchangeOAuthForIdpTokens(sessionToken, provider = 'google') {
                     claims = { decode: 'FAILED — not a well-formed JWT' };
                 }
             }
+            const forwardedAccess = idTokenScope.getStore()?.accessToken;
             console.error('[BETTER_AUTH] exchange diagnostics:', {
                 id_token_forwarded: !!forwarded,
                 id_token_length: forwarded ? forwarded.length : 0,
+                /**
+                 * Read these two for github, and IGNORE the id_token pair above: github
+                 * issues no id_token, so `id_token_forwarded: false` is its NORMAL state
+                 * and not the fault. Presence and length only — an access token is
+                 * credential material and this log is persistent. A github failure with
+                 * access_token_forwarded:true means the IDP called GitHub and refused
+                 * the answer (unverified or non-primary email, or app not installed);
+                 * false means the capture hook never ran and the IDP never called out.
+                 */
+                access_token_forwarded: !!forwardedAccess,
+                access_token_length: forwardedAccess ? forwardedAccess.length : 0,
                 // Absent id_token => the IDP had nothing to verify. Present => compare these
                 // against the client's registered Google credentials on the IDP.
                 aud: claims.aud ?? null,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@payez/next-mvp",
-  "version": "4.4.3",
+  "version": "4.4.4",
   "sideEffects": false,
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
@@ -967,4 +967,4 @@
     "typescript": "^5.4.5",
     "zustand": "^4.5.5"
   }
-}
+}

package/scripts/module-reach.mjs

@@ -117,7 +117,13 @@ function walkJs(dir, acc = []) {
   for (const e of fs.readdirSync(dir, { withFileTypes: true })) {
     const p = path.join(dir, e.name);
     if (e.isDirectory()) walkJs(p, acc);
-    else if (e.isFile() && /\.(js|mjs|cjs)$/.test(e.name)) acc.push(p);
+    // `__`-prefixed files in dist are TEST MUTANTS, never tsc output (measured:
+    // 0 of 245 in a clean dist). Several suites write one next to the real
+    // artifact — so its relative requires resolve — and delete it straight
+    // after, while `node --test` runs other files CONCURRENTLY. Counting one
+    // would make this census non-reproducible (the property the LIVE test
+    // asserts) and reading one after its delete lands is an ENOENT crash.
+    else if (e.isFile() && !e.name.startsWith('__') && /\.(js|mjs|cjs)$/.test(e.name)) acc.push(p);
   }
   return acc;
 }

package/src/api/auth-handler.ts

@@ -15,7 +15,6 @@
 
 import { NextRequest, NextResponse } from 'next/server';
 import { getSession as getBetterAuthSession } from '../server/auth';
-import { resolveAcrLevel, resolveAuthMethods } from '../lib/acr';
 import { nanoid } from 'nanoid';
 import {
   getSession,
@@ -245,24 +244,10 @@ export function createAuthHandler(options: AuthHandlerOptions = {}) {
         return { success: false, error: 'No refresh token' };
       }
 
-      // Extract authentication methods from session.
-      //
-      // 375639: these two lines used to read
-      //     authMethods = ... : ['pwd', 'mfa']
-      //     authLevel   = String(... || ... || '2')
-      // so a session that knew NOTHING about how the user authenticated told
-      // the IDP that a second factor had happened AND named 'mfa' as the
-      // method. The two fabrications corroborated each other, so a downstream
-      // check cross-validating amr against acr would have accepted the pair.
-      // Absent is not satisfied; both now resolve fail-closed, in one place.
-      const authMethods = resolveAuthMethods(
-        (currentSession as any).authMethods,
-        (currentSession as any).token?.amr
-      );
-      const authLevel = resolveAcrLevel(
-        (currentSession as any).authenticationLevel,
-        (currentSession as any).token?.acr
-      );
+      // Extract authentication methods from session
+      const authMethods = (currentSession as any).authMethods ||
+                         ((currentSession as any).token?.amr ? JSON.parse((currentSession as any).token.amr) : ['pwd', 'mfa']);
+      const authLevel = String((currentSession as any).authenticationLevel || (currentSession as any).token?.acr || '2');
       const twoFactorMethod = (currentSession as any).twoFactorMethod || 'authenticator';
 
       // Build refresh request body

package/src/auth/better-auth.ts

@@ -125,12 +125,27 @@ export interface BetterAuthSocialProvider {
  * globalThis is per-process and per-runtime, which is exactly the lifetime a request-scoped
  * carrier needs to be reachable from every copy that might run inside the request.
  */
+/**
+ * THE KEY STAYS '__payezIdTokenScope' EVEN THOUGH THE SCOPE NOW CARRIES TWO
+ * THINGS. Renaming it would give a copy on the old name and a copy on the new
+ * name two DIFFERENT stores in the same process — which is precisely the
+ * double-load failure documented above, reintroduced by a cosmetic rename. The
+ * name is a wire contract between copies, not a description.
+ *
+ * accessToken is here for providers that do NOT issue an id_token. GitHub is
+ * not an OIDC provider: it has no id_token, no JWKS and no discovery document,
+ * so `id_token` can never be the field that proves a GitHub identity. The IDP
+ * re-derives that identity by calling GitHub itself with this access token
+ * (GitHubIdentityVerifier), which keeps the same rule google follows — the IDP
+ * verifies for itself and never trusts an asserted email.
+ */
 const ID_TOKEN_SCOPE_KEY = '__payezIdTokenScope';
+type ProviderTokenScope = { idToken?: string; accessToken?: string };
 const gScope = globalThis as unknown as Record<
   string,
-  AsyncLocalStorage<{ idToken?: string }> | undefined
+  AsyncLocalStorage<ProviderTokenScope> | undefined
 >;
-gScope[ID_TOKEN_SCOPE_KEY] ??= new AsyncLocalStorage<{ idToken?: string }>();
+gScope[ID_TOKEN_SCOPE_KEY] ??= new AsyncLocalStorage<ProviderTokenScope>();
 const idTokenScope = gScope[ID_TOKEN_SCOPE_KEY]!;
 
 /**
@@ -242,10 +257,22 @@ export function buildBetterAuthProviders(
      * remains, so the provider emits exactly its default set.
      */
     const GOOGLE_DEFAULT_SCOPES = ['email', 'profile', 'openid'];
+    /**
+     * Same defect, same fix, different provider: github's createAuthorizationURL
+     * also seeds ['read:user','user:email'] unconditionally and then pushes ours
+     * on top (@better-auth/core social-providers/github.ts), so the stored row
+     * "read:user user:email" reached GitHub as
+     * "read:user user:email read:user user:email". Measured on :4799, not
+     * assumed. GitHub dedupes, so this is legibility rather than function — but
+     * a scope list is the first thing a security reviewer reads off that URL.
+     */
+    const GITHUB_DEFAULT_SCOPES = ['read:user', 'user:email'];
     const wireScopes =
       name === 'google'
         ? scopes.filter((s) => !GOOGLE_DEFAULT_SCOPES.includes(s))
-        : scopes;
+        : name === 'github'
+          ? scopes.filter((s) => !GITHUB_DEFAULT_SCOPES.includes(s))
+          : scopes;
 
     providers[name] = {
       clientId: oauth.clientId,
@@ -350,6 +377,98 @@ export function buildBetterAuthProviders(
         };
       };
     }
+
+    /**
+     * GITHUB: THE SAME CAPTURE, A DIFFERENT TOKEN.
+     *
+     * GitHub is not an OIDC provider — it issues no id_token — so the google
+     * branch above can never fire for it and the exchange would post an
+     * assertion with nothing that proves identity. That is exactly the
+     * 401 UNVERIFIED_ASSERTION measured on :4799, whose diagnostics read
+     * `id_token_forwarded: false, id_token_length: 0` with `response_time_ms: 0`:
+     * the IDP rejected it instantly, without ever calling GitHub.
+     *
+     * getUserInfo is the ONLY provider hook that receives the token set (see the
+     * google note above), and @better-auth/core's github provider calls
+     * `options.getUserInfo(token)` BEFORE its own body — so installing this
+     * REPLACES the default rather than wrapping it, and the default's work has
+     * to be reproduced here or the sign-in loses its profile entirely.
+     *
+     * Mirrored verbatim from @better-auth/core/src/social-providers/github.ts at
+     * the version the container actually runs (better-auth 1.5.6 — the graft's
+     * node_modules says 1.6.29 and is NOT what executes). Kept deliberately
+     * dumb: it must not "improve" on upstream, because every divergence here is
+     * a behaviour change disguised as a token capture.
+     *
+     * This is NOT the identity check. The IDP re-derives the GitHub identity
+     * itself from this access token and enforces primary && verified server-side
+     * (GitHubIdentityVerifier); what we return here only shapes the local
+     * better-auth user record.
+     */
+    if (name === 'github') {
+      (providers[name] as unknown as Record<string, unknown>).getUserInfo = async (token: {
+        accessToken?: string;
+      }) => {
+        const store = idTokenScope.getStore();
+        if (store) {
+          store.accessToken = token?.accessToken;
+        } else {
+          console.warn(
+            '[BETTER_AUTH] github access_token captured but NO REQUEST SCOPE to put it in — ' +
+              'it will NOT be forwarded and the IDP exchange will fail UNVERIFIED_ASSERTION. ' +
+              'Check that GET is createAuthGetHandler(), not routes/auth/nextauth.',
+          );
+        }
+
+        const ghHeaders = {
+          'User-Agent': 'better-auth',
+          Authorization: `Bearer ${token?.accessToken}`,
+        };
+
+        const profileRes = await fetch('https://api.github.com/user', {
+          headers: ghHeaders,
+        });
+        // Upstream returns null on profile error, which fails the sign-in
+        // closed. Preserved rather than softened.
+        if (!profileRes.ok) {
+          console.warn(
+            `[BETTER_AUTH] github getUserInfo: /user returned ${profileRes.status}`,
+          );
+          return null;
+        }
+        const profile = (await profileRes.json()) as Record<string, any>;
+
+        const emailsRes = await fetch('https://api.github.com/user/emails', {
+          headers: ghHeaders,
+        });
+        const emails = emailsRes.ok
+          ? ((await emailsRes.json()) as Array<{
+              email: string;
+              primary: boolean;
+              verified: boolean;
+            }>)
+          : undefined;
+
+        // A GitHub account with a private email returns profile.email = null;
+        // upstream falls back to the primary address here.
+        if (!profile.email && emails) {
+          profile.email = (emails.find((e) => e.primary) ?? emails[0])?.email;
+        }
+        const emailVerified =
+          emails?.find((e) => e.email === profile.email)?.verified ?? false;
+
+        return {
+          user: {
+            id: profile.id,
+            name: profile.name || profile.login || '',
+            email: profile.email,
+            image: profile.avatar_url,
+            emailVerified,
+          },
+          data: profile,
+        };
+      };
+    }
   }
 
   return providers;
@@ -900,6 +1019,21 @@ export async function exchangeOAuthForIdpTokens(
          * distinguishable from "the provider issued none".
          */
         ...(idTokenScope.getStore()?.idToken ? { id_token: idTokenScope.getStore()!.idToken } : {}),
+        /**
+         * The same field for providers that have no id_token to give.
+         *
+         * Identical doctrine to the id_token above: RAW, forwarded verbatim,
+         * NOTHING DERIVED FROM IT, and omitted entirely rather than sent null so
+         * "never captured" stays distinguishable from "provider issued none".
+         * The IDP verifies for itself by calling GitHub with this token and
+         * enforcing primary && verified; we assert nothing about the identity.
+         *
+         * Scoped to the provider access token captured during THIS callback, so
+         * a google login continues to send id_token only and is unaffected.
+         */
+        ...(idTokenScope.getStore()?.accessToken
+          ? { access_token: idTokenScope.getStore()!.accessToken }
+          : {}),
       }),
     });
 
@@ -933,9 +1067,21 @@ export async function exchangeOAuthForIdpTokens(
           claims = { decode: 'FAILED — not a well-formed JWT' };
         }
       }
+      const forwardedAccess = idTokenScope.getStore()?.accessToken;
       console.error('[BETTER_AUTH] exchange diagnostics:', {
         id_token_forwarded: !!forwarded,
         id_token_length: forwarded ? forwarded.length : 0,
+        /**
+         * Read these two for github, and IGNORE the id_token pair above: github
+         * issues no id_token, so `id_token_forwarded: false` is its NORMAL state
+         * and not the fault. Presence and length only — an access token is
+         * credential material and this log is persistent. A github failure with
+         * access_token_forwarded:true means the IDP called GitHub and refused
+         * the answer (unverified or non-primary email, or app not installed);
+         * false means the capture hook never ran and the IDP never called out.
+         */
+        access_token_forwarded: !!forwardedAccess,
+        access_token_length: forwardedAccess ? forwardedAccess.length : 0,
         // Absent id_token => the IDP had nothing to verify. Present => compare these
         // against the client's registered Google credentials on the IDP.
         aud: claims.aud ?? null,

package/dist/lib/acr.d.ts

@@ -1,64 +0,0 @@
-/**
- * CARD 375639 - the one place this package decides what an ABSENT assurance
- * signal means.
- *
- * Card 375276 fixed this question inside `payez_idp_admin_web/src` (commit
- * d9c6ac0, BAPert R980 remedy (a)) and fenced its own scope explicitly:
- *
- *     "fallbacks on the stored `session.authenticationLevel` (refresh lane)
- *      are deliberately NOT covered ... That gap is 375276's remaining half."
- *
- * `src/api/auth-handler.ts` IS that remaining half, and it is in the shared
- * package rather than in one app, so every consumer of the published
- * `@payez/next-mvp/api/auth-handler` export inherits it.
- *
- * WHY BOTH SIGNALS LIVE IN ONE MODULE
- * -----------------------------------
- * `acr` (how strong the authentication was) and `amr` (which methods were
- * used) are sent to the IDP together in a single refresh body. Defaulting one
- * without the other produces an INCOHERENT assertion - "no second factor
- * happened, and the method used was mfa" - so they are resolved side by side
- * and a change to one is forced to confront the other.
- *
- * MEASURED CONVENTION IN THIS PACKAGE (census, 2026-09-11)
- * -------------------------------------------------------
- * acr absent-defaults:  '0' x1, '1' x3, '2' x1   <- the '2' was auth-handler
- * amr absent-defaults:  []  x5, ['pwd','mfa'] x1 <- the list was auth-handler
- *
- * Both fail-open values were outliers at a single site, not the convention.
- * These constants adopt the majority, fail-closed convention.
- */
-/**
- * The assurance level used when the session and token say NOTHING about it.
- *
- * '1' = a single factor. It does not assert that a second factor happened.
- * It must never be '2' (or higher): that is the value the IDP reads as
- * "a second factor was completed", and an absent claim is not evidence of one.
- */
-export declare const ACR_WHEN_ABSENT = "1";
-/**
- * The authentication-methods list used when nothing is known.
- *
- * Empty asserts nothing. It must never contain 'mfa' (or any second-factor
- * method): claiming a method that was never exercised is the same fabrication
- * as ACR '2', and because the two corroborate each other a downstream check
- * that cross-validates amr against acr would accept the fabricated pair.
- */
-export declare const AMR_WHEN_ABSENT: readonly string[];
-/**
- * Resolve an assurance level from any number of candidate sources, in
- * priority order, falling back to the level that asserts no second factor.
- *
- * Accepts the candidates the refresh lane actually has: the stored
- * `session.authenticationLevel` first, then the `acr` claim on the token.
- */
-export declare function resolveAcrLevel(...candidates: unknown[]): string;
-/**
- * Resolve the authentication-methods list.
- *
- * `raw` may arrive as a JSON string (the shape stored on the token) or as an
- * array (the shape held on the session). Anything unparseable resolves to the
- * empty list rather than to an assumed set of methods - a malformed claim is
- * not evidence that mfa happened.
- */
-export declare function resolveAuthMethods(...candidates: unknown[]): string[];

package/dist/lib/acr.js

@@ -1,109 +0,0 @@
-"use strict";
-/**
- * CARD 375639 - the one place this package decides what an ABSENT assurance
- * signal means.
- *
- * Card 375276 fixed this question inside `payez_idp_admin_web/src` (commit
- * d9c6ac0, BAPert R980 remedy (a)) and fenced its own scope explicitly:
- *
- *     "fallbacks on the stored `session.authenticationLevel` (refresh lane)
- *      are deliberately NOT covered ... That gap is 375276's remaining half."
- *
- * `src/api/auth-handler.ts` IS that remaining half, and it is in the shared
- * package rather than in one app, so every consumer of the published
- * `@payez/next-mvp/api/auth-handler` export inherits it.
- *
- * WHY BOTH SIGNALS LIVE IN ONE MODULE
- * -----------------------------------
- * `acr` (how strong the authentication was) and `amr` (which methods were
- * used) are sent to the IDP together in a single refresh body. Defaulting one
- * without the other produces an INCOHERENT assertion - "no second factor
- * happened, and the method used was mfa" - so they are resolved side by side
- * and a change to one is forced to confront the other.
- *
- * MEASURED CONVENTION IN THIS PACKAGE (census, 2026-09-11)
- * -------------------------------------------------------
- * acr absent-defaults:  '0' x1, '1' x3, '2' x1   <- the '2' was auth-handler
- * amr absent-defaults:  []  x5, ['pwd','mfa'] x1 <- the list was auth-handler
- *
- * Both fail-open values were outliers at a single site, not the convention.
- * These constants adopt the majority, fail-closed convention.
- */
-Object.defineProperty(exports, "__esModule", { value: true });
-exports.AMR_WHEN_ABSENT = exports.ACR_WHEN_ABSENT = void 0;
-exports.resolveAcrLevel = resolveAcrLevel;
-exports.resolveAuthMethods = resolveAuthMethods;
-/**
- * The assurance level used when the session and token say NOTHING about it.
- *
- * '1' = a single factor. It does not assert that a second factor happened.
- * It must never be '2' (or higher): that is the value the IDP reads as
- * "a second factor was completed", and an absent claim is not evidence of one.
- */
-exports.ACR_WHEN_ABSENT = '1';
-/**
- * The authentication-methods list used when nothing is known.
- *
- * Empty asserts nothing. It must never contain 'mfa' (or any second-factor
- * method): claiming a method that was never exercised is the same fabrication
- * as ACR '2', and because the two corroborate each other a downstream check
- * that cross-validates amr against acr would accept the fabricated pair.
- */
-exports.AMR_WHEN_ABSENT = [];
-/**
- * True when an assurance signal carries no information.
- *
- * Deliberately NOT `!value`. The `||` idiom this replaces cannot tell
- * "the token said nothing" from "the token said 0", and numeric 0 is a
- * meaningful assurance level (unauthenticated) that must survive as '0'
- * rather than being promoted to the fallback.
- */
-function isAbsent(value) {
-    return value === undefined || value === null || value === '';
-}
-/**
- * Resolve an assurance level from any number of candidate sources, in
- * priority order, falling back to the level that asserts no second factor.
- *
- * Accepts the candidates the refresh lane actually has: the stored
- * `session.authenticationLevel` first, then the `acr` claim on the token.
- */
-function resolveAcrLevel(...candidates) {
-    for (const candidate of candidates) {
-        if (!isAbsent(candidate)) {
-            return String(candidate);
-        }
-    }
-    return exports.ACR_WHEN_ABSENT;
-}
-/**
- * Resolve the authentication-methods list.
- *
- * `raw` may arrive as a JSON string (the shape stored on the token) or as an
- * array (the shape held on the session). Anything unparseable resolves to the
- * empty list rather than to an assumed set of methods - a malformed claim is
- * not evidence that mfa happened.
- */
-function resolveAuthMethods(...candidates) {
-    for (const candidate of candidates) {
-        if (isAbsent(candidate))
-            continue;
-        if (Array.isArray(candidate)) {
-            return candidate.map(String);
-        }
-        if (typeof candidate === 'string') {
-            try {
-                const parsed = JSON.parse(candidate);
-                if (Array.isArray(parsed)) {
-                    return parsed.map(String);
-                }
-            }
-            catch {
-                // A malformed amr claim asserts nothing. Fall through to the next
-                // candidate rather than inventing methods.
-                continue;
-            }
-        }
-    }
-    return [...exports.AMR_WHEN_ABSENT];
-}

package/src/lib/acr.ts

@@ -1,109 +0,0 @@
-/**
- * CARD 375639 - the one place this package decides what an ABSENT assurance
- * signal means.
- *
- * Card 375276 fixed this question inside `payez_idp_admin_web/src` (commit
- * d9c6ac0, BAPert R980 remedy (a)) and fenced its own scope explicitly:
- *
- *     "fallbacks on the stored `session.authenticationLevel` (refresh lane)
- *      are deliberately NOT covered ... That gap is 375276's remaining half."
- *
- * `src/api/auth-handler.ts` IS that remaining half, and it is in the shared
- * package rather than in one app, so every consumer of the published
- * `@payez/next-mvp/api/auth-handler` export inherits it.
- *
- * WHY BOTH SIGNALS LIVE IN ONE MODULE
- * -----------------------------------
- * `acr` (how strong the authentication was) and `amr` (which methods were
- * used) are sent to the IDP together in a single refresh body. Defaulting one
- * without the other produces an INCOHERENT assertion - "no second factor
- * happened, and the method used was mfa" - so they are resolved side by side
- * and a change to one is forced to confront the other.
- *
- * MEASURED CONVENTION IN THIS PACKAGE (census, 2026-09-11)
- * -------------------------------------------------------
- * acr absent-defaults:  '0' x1, '1' x3, '2' x1   <- the '2' was auth-handler
- * amr absent-defaults:  []  x5, ['pwd','mfa'] x1 <- the list was auth-handler
- *
- * Both fail-open values were outliers at a single site, not the convention.
- * These constants adopt the majority, fail-closed convention.
- */
-
-/**
- * The assurance level used when the session and token say NOTHING about it.
- *
- * '1' = a single factor. It does not assert that a second factor happened.
- * It must never be '2' (or higher): that is the value the IDP reads as
- * "a second factor was completed", and an absent claim is not evidence of one.
- */
-export const ACR_WHEN_ABSENT = '1';
-
-/**
- * The authentication-methods list used when nothing is known.
- *
- * Empty asserts nothing. It must never contain 'mfa' (or any second-factor
- * method): claiming a method that was never exercised is the same fabrication
- * as ACR '2', and because the two corroborate each other a downstream check
- * that cross-validates amr against acr would accept the fabricated pair.
- */
-export const AMR_WHEN_ABSENT: readonly string[] = [];
-
-/**
- * True when an assurance signal carries no information.
- *
- * Deliberately NOT `!value`. The `||` idiom this replaces cannot tell
- * "the token said nothing" from "the token said 0", and numeric 0 is a
- * meaningful assurance level (unauthenticated) that must survive as '0'
- * rather than being promoted to the fallback.
- */
-function isAbsent(value: unknown): boolean {
-  return value === undefined || value === null || value === '';
-}
-
-/**
- * Resolve an assurance level from any number of candidate sources, in
- * priority order, falling back to the level that asserts no second factor.
- *
- * Accepts the candidates the refresh lane actually has: the stored
- * `session.authenticationLevel` first, then the `acr` claim on the token.
- */
-export function resolveAcrLevel(...candidates: unknown[]): string {
-  for (const candidate of candidates) {
-    if (!isAbsent(candidate)) {
-      return String(candidate);
-    }
-  }
-  return ACR_WHEN_ABSENT;
-}
-
-/**
- * Resolve the authentication-methods list.
- *
- * `raw` may arrive as a JSON string (the shape stored on the token) or as an
- * array (the shape held on the session). Anything unparseable resolves to the
- * empty list rather than to an assumed set of methods - a malformed claim is
- * not evidence that mfa happened.
- */
-export function resolveAuthMethods(...candidates: unknown[]): string[] {
-  for (const candidate of candidates) {
-    if (isAbsent(candidate)) continue;
-
-    if (Array.isArray(candidate)) {
-      return candidate.map(String);
-    }
-
-    if (typeof candidate === 'string') {
-      try {
-        const parsed = JSON.parse(candidate);
-        if (Array.isArray(parsed)) {
-          return parsed.map(String);
-        }
-      } catch {
-        // A malformed amr claim asserts nothing. Fall through to the next
-        // candidate rather than inventing methods.
-        continue;
-      }
-    }
-  }
-  return [...AMR_WHEN_ABSENT];
-}