@adonis-agora/authkit-server 0.72.0 → 0.74.0

package/build/src/host/admin_validators.js

@@ -1,4 +1,5 @@
 import vine from '@vinejs/vine';
+import { APPLICATION_TYPES, redirectUriProblem } from './client_metadata.js';
 import { normalizeEmailIdentifier } from './email_identifier.js';
 /**
  * Validators VineJS dos recursos administrativos (Admin REST API + console admin).
@@ -42,8 +43,25 @@ const authMethod = vine.enum(['client_secret_basic', 'client_secret_post', 'none
  * (`require_tld:false`) p/ não rejeitar `localhost` ou hostnames internos legítimos.
  */
 const URL_OPTS = { require_protocol: true, require_tld: false, protocols: ['http', 'https'] };
-/** Array de URIs ABSOLUTAS http/https. Rejeita strings que não são URL válida. */
-const urlArray = vine.array(vine.string().trim().url(URL_OPTS));
+/**
+ * Regra de redirect URI ciente do `applicationType` do MESMO payload (RFC 8252):
+ * client web continua restrito a http/https (L10); client nativo aceita esquema
+ * privado (`com.example.app:/cb`), https claimed e loopback http. Sem o tipo no
+ * payload (PATCH parcial) só as regras universais valem aqui — URI absoluta, sem
+ * fragmento, sem `javascript:`/`data:`/… — e o `AdminClientsService` confere o
+ * resto contra o tipo EFETIVO do client (ver `client_metadata.ts`).
+ */
+const redirectUriRule = vine.createRule((value, _options, field) => {
+    if (typeof value !== 'string')
+        return;
+    const declared = field.data?.applicationType;
+    const type = declared === 'web' || declared === 'native' ? declared : undefined;
+    const problem = redirectUriProblem(value, type);
+    if (problem)
+        field.report(`The {{ field }} field ${problem}`, 'redirectUri', field);
+});
+/** Array de redirect URIs (ver {@link redirectUriRule}). Rejeita strings que não são URI válida. */
+const redirectUriArray = vine.array(vine.string().trim().use(redirectUriRule()));
 /**
  * Allowlist de grant_types aceitos no registro/edição de client (M10). Bloqueia
  * `implicit` (tokens no fragment da URL — sem PKCE/refresh) e qualquer valor fora
@@ -70,10 +88,12 @@ const grantTypeArray = vine.array(vine.enum(ALLOWED_GRANT_TYPES));
  */
 export const clientInputValidator = vine.compile(vine.object({
     clientId: vine.string().trim().optional(),
-    // redirect/postLogout: URIs ABSOLUTAS (L10). `vine.string().url()` rejeita
-    // valores que não são URL (ex.: 'javascript:...', paths relativos).
-    redirectUris: urlArray.optional(),
-    postLogoutRedirectUris: urlArray.optional(),
+    // `web` (default) ou `native` (RFC 8252 — app mobile/desktop, sempre público).
+    applicationType: vine.enum(APPLICATION_TYPES).optional(),
+    // redirect/postLogout: URIs ABSOLUTAS (L10), http/https para client web;
+    // esquema privado/loopback só para `native` (ver `redirectUriRule`).
+    redirectUris: redirectUriArray.optional(),
+    postLogoutRedirectUris: redirectUriArray.optional(),
     // grant_types restrito à allowlist; `implicit` e desconhecidos viram 422 (M10).
     grantTypes: grantTypeArray.optional(),
     grants: grantTypeArray.optional(),
@@ -82,14 +102,20 @@ export const clientInputValidator = vine.compile(vine.object({
     backchannelLogoutUri: vine.string().trim().url(URL_OPTS).optional(),
     backchannelLogoutSessionRequired: vine.boolean().optional(),
 }));
-/** Mapeia o input validado para um {@link ClientInput} COMPLETO (create), com defaults. */
+/**
+ * Mapeia o input validado para um {@link ClientInput} COMPLETO (create), com defaults.
+ * Client nativo sem `tokenEndpointAuthMethod` explícito vira público (`none`); um
+ * nativo confidencial explícito é recusado pelo service (422).
+ */
 export function clientCreateInput(v) {
+    const applicationType = v.applicationType ?? 'web';
     return {
         clientId: v.clientId?.trim() || undefined,
+        applicationType,
         redirectUris: v.redirectUris ?? [],
         postLogoutRedirectUris: v.postLogoutRedirectUris ?? [],
         grantTypes: v.grantTypes ?? v.grants ?? [],
-        tokenEndpointAuthMethod: v.tokenEndpointAuthMethod ?? 'client_secret_basic',
+        tokenEndpointAuthMethod: v.tokenEndpointAuthMethod ?? (applicationType === 'native' ? 'none' : 'client_secret_basic'),
         backchannelLogoutUri: v.backchannelLogoutUri || undefined,
         backchannelLogoutSessionRequired: v.backchannelLogoutSessionRequired,
     };
@@ -100,6 +126,8 @@ export function clientCreateInput(v) {
  */
 export function clientPartialInput(v) {
     const out = {};
+    if (v.applicationType !== undefined)
+        out.applicationType = v.applicationType;
     if (v.redirectUris !== undefined)
         out.redirectUris = v.redirectUris;
     if (v.postLogoutRedirectUris !== undefined)

package/build/src/host/bearer_account.d.ts

@@ -0,0 +1,9 @@
+/** Registra a conta autenticada via bearer nesta request. */
+export declare function setBearerAccountId(ctx: object, accountId: string): void;
+/** Esquece a conta bearer desta request (falha de autenticação). */
+export declare function clearBearerAccountId(ctx: object): void;
+/**
+ * Id da conta autenticada via bearer nesta request, ou `null` quando nenhum
+ * `oidcBearerGuard` autenticou (ainda) a request.
+ */
+export declare function bearerAccountId(ctx: object): string | null;

package/build/src/host/bearer_account.js

@@ -0,0 +1,28 @@
+/**
+ * Conta autenticada por `Authorization: Bearer` NESTA request — gravada pelo
+ * `oidcBearerGuard` quando ele autentica e lida pelo `getAccountId` como
+ * fallback da sessão.
+ *
+ * Um `WeakMap` keyed pelo próprio `HttpContext` (e não uma prop em `ctx`): nada
+ * de augmentation de `HttpContext` vazando pelo barrel (ver o porquê em
+ * `account_session_key.ts`), e o valor morre junto com a request.
+ *
+ * Mantenha este arquivo sem imports: `console_session.ts` (reexportado pelo
+ * barrel) depende dele.
+ */
+const bearerAccounts = new WeakMap();
+/** Registra a conta autenticada via bearer nesta request. */
+export function setBearerAccountId(ctx, accountId) {
+    bearerAccounts.set(ctx, accountId);
+}
+/** Esquece a conta bearer desta request (falha de autenticação). */
+export function clearBearerAccountId(ctx) {
+    bearerAccounts.delete(ctx);
+}
+/**
+ * Id da conta autenticada via bearer nesta request, ou `null` quando nenhum
+ * `oidcBearerGuard` autenticou (ainda) a request.
+ */
+export function bearerAccountId(ctx) {
+    return bearerAccounts.get(ctx) ?? null;
+}

package/build/src/host/client_metadata.d.ts

@@ -0,0 +1,51 @@
+/**
+ * Regras de metadata de client que dependem do TIPO de aplicação (OIDC
+ * Registration §2, `application_type`) — compartilhadas pelo
+ * {@link AdminClientsService} (console admin, Admin REST API, CLI, import) e pelo
+ * validator Vine de `admin_validators.ts`.
+ *
+ * Espelham as regras que o próprio oidc-provider aplica ao montar o `Client`
+ * (`helpers/client_schema.js#redirectUris`). Checamos ANTES de persistir porque o
+ * provider só valida no `Client.find` — um client inválido gravado no adapter
+ * vira "client não encontrado" em runtime, sem mensagem útil para quem o criou.
+ *
+ * `native` segue a RFC 8252 (OAuth 2.0 for Native Apps):
+ *   - esquema privado (`com.example.app:/callback`, `myapp://auth`) — §7.1;
+ *   - https "claimed" (universal links / app links), nunca em loopback — §7.2;
+ *   - loopback `http://127.0.0.1:<qualquer porta>/…` (e `localhost`/`[::1]`) — §7.3.
+ *     O provider ignora a porta do loopback na comparação do redirect (§7.3), então
+ *     basta registrar `http://127.0.0.1/callback`.
+ *   - client PÚBLICO: um segredo embarcado num app instalado não é segredo (§8.5).
+ *     PKCE (S256) já é obrigatório para todo client neste issuer.
+ */
+/** Tipo de aplicação do client. `web` é o default histórico. */
+export type ApplicationType = 'web' | 'native';
+export declare const APPLICATION_TYPES: readonly ['web', 'native'];
+/**
+ * Metadata inválida para o tipo de client (ex.: client nativo com secret, redirect
+ * `myapp://` num client web). Os controllers traduzem em 422.
+ */
+export declare class ClientMetadataError extends Error {
+    constructor(message: string);
+}
+/**
+ * Problema de UMA redirect URI para o tipo de client, ou `null` quando ok.
+ *
+ * `applicationType` ausente = "ainda não sei" (PATCH que não mandou o tipo): só as
+ * regras universais (URI absoluta, sem fragmento, esquema não proibido). A regra
+ * por tipo roda depois, no service, com o tipo efetivo do client.
+ */
+export declare function redirectUriProblem(uri: string, applicationType?: ApplicationType): string | null;
+/** Entrada mínima para {@link assertClientMetadata}. */
+export interface ClientMetadataInput {
+    applicationType: ApplicationType;
+    tokenEndpointAuthMethod: string;
+    grantTypes: string[];
+    redirectUris: string[];
+    postLogoutRedirectUris: string[];
+}
+/**
+ * Valida a combinação tipo × autenticação × grants × redirects. Lança
+ * {@link ClientMetadataError} na primeira violação.
+ */
+export declare function assertClientMetadata(input: ClientMetadataInput): void;

package/build/src/host/client_metadata.js

@@ -0,0 +1,98 @@
+/**
+ * Regras de metadata de client que dependem do TIPO de aplicação (OIDC
+ * Registration §2, `application_type`) — compartilhadas pelo
+ * {@link AdminClientsService} (console admin, Admin REST API, CLI, import) e pelo
+ * validator Vine de `admin_validators.ts`.
+ *
+ * Espelham as regras que o próprio oidc-provider aplica ao montar o `Client`
+ * (`helpers/client_schema.js#redirectUris`). Checamos ANTES de persistir porque o
+ * provider só valida no `Client.find` — um client inválido gravado no adapter
+ * vira "client não encontrado" em runtime, sem mensagem útil para quem o criou.
+ *
+ * `native` segue a RFC 8252 (OAuth 2.0 for Native Apps):
+ *   - esquema privado (`com.example.app:/callback`, `myapp://auth`) — §7.1;
+ *   - https "claimed" (universal links / app links), nunca em loopback — §7.2;
+ *   - loopback `http://127.0.0.1:<qualquer porta>/…` (e `localhost`/`[::1]`) — §7.3.
+ *     O provider ignora a porta do loopback na comparação do redirect (§7.3), então
+ *     basta registrar `http://127.0.0.1/callback`.
+ *   - client PÚBLICO: um segredo embarcado num app instalado não é segredo (§8.5).
+ *     PKCE (S256) já é obrigatório para todo client neste issuer.
+ */
+export const APPLICATION_TYPES = ['web', 'native'];
+/** Hosts loopback reconhecidos (mesma lista do oidc-provider). */
+const LOOPBACKS = new Set(['localhost', '127.0.0.1', '[::1]']);
+/** Esquemas NUNCA aceitos como redirect, qualquer que seja o tipo de client. */
+const FORBIDDEN_SCHEMES = new Set([
+    'javascript:',
+    'vbscript:',
+    'data:',
+    'blob:',
+    'file:',
+    'about:',
+]);
+/**
+ * Metadata inválida para o tipo de client (ex.: client nativo com secret, redirect
+ * `myapp://` num client web). Os controllers traduzem em 422.
+ */
+export class ClientMetadataError extends Error {
+    constructor(message) {
+        super(message);
+        this.name = 'ClientMetadataError';
+    }
+}
+/**
+ * Problema de UMA redirect URI para o tipo de client, ou `null` quando ok.
+ *
+ * `applicationType` ausente = "ainda não sei" (PATCH que não mandou o tipo): só as
+ * regras universais (URI absoluta, sem fragmento, esquema não proibido). A regra
+ * por tipo roda depois, no service, com o tipo efetivo do client.
+ */
+export function redirectUriProblem(uri, applicationType) {
+    const parsed = URL.parse(uri);
+    if (!parsed)
+        return 'deve ser uma URI absoluta';
+    if (uri.includes('#'))
+        return 'não pode conter fragmento (#)';
+    const { protocol, hostname } = parsed;
+    if (FORBIDDEN_SCHEMES.has(protocol))
+        return `não pode usar o esquema ${protocol.slice(0, -1)}`;
+    if (applicationType === 'web') {
+        if (protocol !== 'http:' && protocol !== 'https:') {
+            return 'client web só aceita URIs http/https (use applicationType "native" para apps mobile)';
+        }
+    }
+    else if (applicationType === 'native') {
+        if (protocol === 'http:' && !LOOPBACKS.has(hostname)) {
+            return 'client nativo com http só aceita loopback (127.0.0.1, [::1] ou localhost)';
+        }
+        if (protocol === 'https:' && LOOPBACKS.has(hostname)) {
+            return 'client nativo com https "claimed" não pode usar host loopback';
+        }
+    }
+    return null;
+}
+/**
+ * Valida a combinação tipo × autenticação × grants × redirects. Lança
+ * {@link ClientMetadataError} na primeira violação.
+ */
+export function assertClientMetadata(input) {
+    const type = input.applicationType;
+    if (type === 'native') {
+        if (input.tokenEndpointAuthMethod !== 'none') {
+            throw new ClientMetadataError('client nativo precisa ser público (tokenEndpointAuthMethod "none", sem secret) — RFC 8252 §8.5');
+        }
+        if (input.grantTypes.includes('client_credentials')) {
+            throw new ClientMetadataError('client nativo não pode usar client_credentials (não há secret para autenticar)');
+        }
+    }
+    for (const [label, uris] of [
+        ['redirectUris', input.redirectUris],
+        ['postLogoutRedirectUris', input.postLogoutRedirectUris],
+    ]) {
+        for (const uri of uris) {
+            const problem = redirectUriProblem(uri, type);
+            if (problem)
+                throw new ClientMetadataError(`${label}: "${uri}" ${problem}`);
+        }
+    }
+}

package/build/src/host/console_session.d.ts

@@ -9,8 +9,18 @@ import type { HttpContext } from '@adonisjs/core/http';
  * sessão mudar.
  */
 /**
- * Retorna o id da conta que o request está representando no console (ou `null`
- * quando não há sessão).
+ * Retorna o id da conta que o request está representando (ou `null` quando não
+ * há identidade).
+ *
+ * Fonte, nesta ordem:
+ *   1. a sessão do console (`ACCOUNT_SESSION_KEY`) — o comportamento de sempre;
+ *   2. SEM sessão logada: a conta que um `oidcBearerGuard` autenticou NESTA
+ *      request via `Authorization: Bearer` (app nativo, SPA, serviço).
+ *
+ * O fallback (2) só existe depois que o guard bearer RODOU na request (ex.:
+ * `middleware.auth({ guards: ['web', 'api'] })` ou `auth.authenticateUsing`);
+ * um app que não usa o guard bearer continua exatamente como antes. A sessão
+ * sempre ganha: request com cookie de sessão E bearer responde pela sessão.
  *
  * ATENÇÃO: com impersonation ativa isto é a conta PERSONIFICADA, não o admin
  * que a personificou. É o comportamento certo para "como qual conta este
@@ -50,7 +60,8 @@ export declare function getAccountId(ctx: HttpContext): string | null;
  */
 export declare function realAccountId(ctx: HttpContext): string | null;
 /**
- * `true` quando o request carrega uma sessão de conta do console.
+ * `true` quando o request carrega uma sessão de conta do console. Só a SESSÃO:
+ * uma identidade bearer (`oidcBearerGuard`) não conta — use `getAccountId`.
  */
 export declare function hasAccountSession(ctx: HttpContext): boolean;
 /**

package/build/src/host/console_session.js

@@ -1,5 +1,6 @@
 import { getAccountLoginUrl } from './account_login_url.js';
 import { ACCOUNT_SESSION_KEY } from './account_session_key.js';
+import { bearerAccountId } from './bearer_account.js';
 import { impersonationState } from './impersonation_session.js';
 /**
  * Helpers públicos para integrar a sessão do console do AuthKit com
@@ -11,8 +12,18 @@ import { impersonationState } from './impersonation_session.js';
  * sessão mudar.
  */
 /**
- * Retorna o id da conta que o request está representando no console (ou `null`
- * quando não há sessão).
+ * Retorna o id da conta que o request está representando (ou `null` quando não
+ * há identidade).
+ *
+ * Fonte, nesta ordem:
+ *   1. a sessão do console (`ACCOUNT_SESSION_KEY`) — o comportamento de sempre;
+ *   2. SEM sessão logada: a conta que um `oidcBearerGuard` autenticou NESTA
+ *      request via `Authorization: Bearer` (app nativo, SPA, serviço).
+ *
+ * O fallback (2) só existe depois que o guard bearer RODOU na request (ex.:
+ * `middleware.auth({ guards: ['web', 'api'] })` ou `auth.authenticateUsing`);
+ * um app que não usa o guard bearer continua exatamente como antes. A sessão
+ * sempre ganha: request com cookie de sessão E bearer responde pela sessão.
  *
  * ATENÇÃO: com impersonation ativa isto é a conta PERSONIFICADA, não o admin
  * que a personificou. É o comportamento certo para "como qual conta este
@@ -21,7 +32,7 @@ import { impersonationState } from './impersonation_session.js';
  */
 export function getAccountId(ctx) {
     const accountId = ctx.session?.get(ACCOUNT_SESSION_KEY);
-    return accountId ?? null;
+    return accountId ?? bearerAccountId(ctx);
 }
 /**
  * Retorna o id do HUMANO real por trás do request — o id que uma decisão de
@@ -54,18 +65,19 @@ export function getAccountId(ctx) {
  * if (!id || !(await authz.hasRole(id, 'admin'))) throw new Error('forbidden')
  */
 export function realAccountId(ctx) {
-    // Sem sessão não há nem impersonation nem conta: mesma tolerância do
-    // `getAccountId` (que usa `ctx.session?.`), pois `impersonationState` assume
-    // uma sessão presente.
+    // Sem sessão não há impersonation: mesma tolerância do `getAccountId` (que usa
+    // `ctx.session?.`), pois `impersonationState` assume uma sessão presente. Resta
+    // a identidade bearer (se o `oidcBearerGuard` autenticou a request).
     if (!ctx.session)
-        return null;
+        return bearerAccountId(ctx);
     return impersonationState(ctx).impersonatorId ?? getAccountId(ctx);
 }
 /**
- * `true` quando o request carrega uma sessão de conta do console.
+ * `true` quando o request carrega uma sessão de conta do console. Só a SESSÃO:
+ * uma identidade bearer (`oidcBearerGuard`) não conta — use `getAccountId`.
  */
 export function hasAccountSession(ctx) {
-    return getAccountId(ctx) !== null;
+    return ctx.session?.get(ACCOUNT_SESSION_KEY) != null;
 }
 /**
  * URL do login do console, com `return_to` opcional de volta ao destino

package/build/src/host/controllers/account_orgs_controller.js

@@ -6,6 +6,7 @@ import { ACCOUNT_SESSION_KEY } from '../account_session_key.js';
 import { ACTIVE_ORG_COOKIE, ACTIVE_ORG_COOKIE_TTL, encodeActiveOrgCookie, } from '../active_org_cookie.js';
 import { sendOrgInvitationEmail } from '../default_mailer.js';
 import { ensureConsoleSession } from '../idp_session_bridge.js';
+import { revokeOrgAccess } from '../org_access_revocation.js';
 // Política efetiva compartilhada com o espelho JSON (`account_orgs_api_controller`):
 // ponto de verdade único, para as duas superfícies nunca divergirem.
 import { effectiveOrgPolicy, orgPolicyDefaults } from '../org_policy.js';
@@ -154,6 +155,7 @@ export default class AccountOrgsController {
             return response.forbidden();
         const result = await store.removeOrgMember(params.id, accountId);
         if (result.ok) {
+            await revokeOrgAccess(service, params.id, accountId);
             await cfg.audit?.record({
                 type: 'organization.member_removed',
                 accountId,
@@ -314,6 +316,7 @@ export default class AccountOrgsController {
         }
         const result = await store.removeOrgMember(params.id, params.accountId);
         if (result.ok) {
+            await revokeOrgAccess(service, params.id, params.accountId);
             await cfg.audit?.record({
                 type: 'organization.member_removed',
                 actorId,

package/build/src/host/controllers/interaction_controller.d.ts

@@ -41,6 +41,22 @@ export default class AuthInteractionController {
      * Retorna `undefined` quando não há step-up — completeLogin usa o default.
      */
     private stepUpExtra;
+    /**
+     * acr/amr de um login que PASSOU pelo desafio do 2º fator: `amr` =
+     * `[primário, 'mfa', método]` (RFC 8176), SEMPRE — não só no step-up. Antes o
+     * `completeLogin` só recebia amr no step-up; fora dele o id_token saía sem `amr`
+     * nenhum, e o fator primário (senha ou e-mail) se perdia. O step-up continua
+     * carimbando o `acr`.
+     *
+     * `primary` ausente (sessão gravada antes desta versão, ou valor adulterado):
+     * o amr sai sem o primário, em vez de inventar um.
+     */
+    private mfaCompletion;
+    /**
+     * Lê E esquece o desafio pendente do 2º fator (accountId + fator primário). Os
+     * dois saem juntos: um primário sobrando na sessão não pode colar no próximo login.
+     */
+    private takeMfaPending;
     /**
      * Gate do segundo fator, compartilhado pelos caminhos de login: senha, link
      * mágico, código por e-mail e troca forçada de senha. Antes disto só o login
@@ -60,7 +76,8 @@ export default class AuthInteractionController {
      *    instrução de enrolar (não há o que desafiar);
      *  - fator presente, trusted-device válido e sem step-up → `trusted`; quem
      *    chamou decide como finalizar, porque o amr muda conforme o caminho;
-     *  - caso geral → `challenge`, com o accountId em `MFA_PENDING_KEY`.
+     *  - caso geral → `challenge`, com o accountId em `MFA_PENDING_KEY` e o fator
+     *    primário (`primary`) em `MFA_PRIMARY_KEY`.
      */
     private secondFactorGate;
     /**

package/build/src/host/controllers/interaction_controller.js

@@ -45,6 +45,12 @@ function accountStatusErrorKey(reason) {
 const SESSION_KEY = 'authkit_login_email';
 /** accountId aguardando o 2º fator depois da senha verificada. */
 const MFA_PENDING_KEY = 'authkit_mfa_pending';
+/**
+ * Fator PRIMÁRIO que levou ao desafio do 2º fator (`pwd` ou `email`), guardado JUNTO
+ * do {@link MFA_PENDING_KEY}. Sem ele, quem completa o 2º fator não sabe como o login
+ * começou e o `amr` do id_token perdia o primeiro fator (ver `mfaCompletion`).
+ */
+const MFA_PRIMARY_KEY = 'authkit_mfa_primary';
 /** Desafio WebAuthn pendente (autenticação) guardado entre begin/finish no login. */
 const PASSKEY_AUTH_CHALLENGE_KEY = 'authkit_passkey_auth_challenge';
 /**
@@ -408,7 +414,7 @@ export default class AuthInteractionController {
         // Gate do 2º fator — a MESMA regra dos três caminhos de login (ver
         // `secondFactorGate`). Quando desafia, não finaliza a interaction: guarda o
         // accountId pendente e devolve a tela.
-        const gate = await this.secondFactorGate(ctx, cfg, acc.id, details);
+        const gate = await this.secondFactorGate(ctx, cfg, acc.id, details, 'pwd');
         if (gate.kind === 'challenge')
             return gate.response;
         if (gate.kind === 'trusted') {
@@ -556,7 +562,7 @@ export default class AuthInteractionController {
         // Sucesso no 2º fator: opcionalmente confia neste dispositivo (checkbox).
         await this.maybeTrustDevice(ctx, cfg, accountId);
         // Finaliza a interaction para o accountId pendente.
-        ctx.session.forget(MFA_PENDING_KEY);
+        const { primary } = this.takeMfaPending(ctx);
         forgetLoginEmail(ctx);
         await notifyLoginSuccess(ctx, cfg, {
             accountId,
@@ -564,9 +570,9 @@ export default class AuthInteractionController {
             clientId,
             metadata: { mfa: usedRecovery ? 'recovery' : 'totp' },
         });
-        // Step-up: um 2º fator foi de fato verificado — carimba acr/amr no id_token
-        // se o client solicitou o mfaAcr nesta requisição.
-        await service.interactions.completeLogin(ctx, accountId, this.stepUpExtra(cfg, details, usedRecovery ? 'recovery' : 'totp'));
+        // Um 2º fator foi de fato verificado: amr = [primário, 'mfa', método]. Com
+        // step-up (mfaAcr solicitado nesta requisição), carimba também o acr.
+        await service.interactions.completeLogin(ctx, accountId, this.mfaCompletion(cfg, details, primary, usedRecovery ? 'recovery' : 'totp'));
     }
     /**
      * true se o authorize request exige MFA via acr_values (contém o mfaAcr da
@@ -591,6 +597,31 @@ export default class AuthInteractionController {
             return undefined;
         return { acr: cfg.stepUp.mfaAcr, amr: ['mfa', method] };
     }
+    /**
+     * acr/amr de um login que PASSOU pelo desafio do 2º fator: `amr` =
+     * `[primário, 'mfa', método]` (RFC 8176), SEMPRE — não só no step-up. Antes o
+     * `completeLogin` só recebia amr no step-up; fora dele o id_token saía sem `amr`
+     * nenhum, e o fator primário (senha ou e-mail) se perdia. O step-up continua
+     * carimbando o `acr`.
+     *
+     * `primary` ausente (sessão gravada antes desta versão, ou valor adulterado):
+     * o amr sai sem o primário, em vez de inventar um.
+     */
+    mfaCompletion(cfg, details, primary, method) {
+        const amr = [...(primary ? [primary] : []), 'mfa', method];
+        const stepUp = this.stepUpExtra(cfg, details, method);
+        return stepUp ? { acr: stepUp.acr, amr } : { amr };
+    }
+    /**
+     * Lê E esquece o desafio pendente do 2º fator (accountId + fator primário). Os
+     * dois saem juntos: um primário sobrando na sessão não pode colar no próximo login.
+     */
+    takeMfaPending(ctx) {
+        const raw = ctx.session.get(MFA_PRIMARY_KEY);
+        ctx.session.forget(MFA_PENDING_KEY);
+        ctx.session.forget(MFA_PRIMARY_KEY);
+        return { primary: raw === 'pwd' || raw === 'email' ? raw : undefined };
+    }
     /**
      * Gate do segundo fator, compartilhado pelos caminhos de login: senha, link
      * mágico, código por e-mail e troca forçada de senha. Antes disto só o login
@@ -610,9 +641,10 @@ export default class AuthInteractionController {
      *    instrução de enrolar (não há o que desafiar);
      *  - fator presente, trusted-device válido e sem step-up → `trusted`; quem
      *    chamou decide como finalizar, porque o amr muda conforme o caminho;
-     *  - caso geral → `challenge`, com o accountId em `MFA_PENDING_KEY`.
+     *  - caso geral → `challenge`, com o accountId em `MFA_PENDING_KEY` e o fator
+     *    primário (`primary`) em `MFA_PRIMARY_KEY`.
      */
-    async secondFactorGate(ctx, cfg, accountId, details) {
+    async secondFactorGate(ctx, cfg, accountId, details, primary) {
         const mfaRequired = this.acrRequiresMfa(cfg, details);
         const mfa = (await cfg.accountStore.getMfaState?.(accountId)) ?? { enabled: false };
         // Passkey disponível como alternativa ao TOTP se o store suporta E a conta
@@ -647,6 +679,9 @@ export default class AuthInteractionController {
                 return { kind: 'trusted' };
         }
         ctx.session.put(MFA_PENDING_KEY, accountId);
+        // O fator primário viaja junto: quem completa o desafio (TOTP, recovery ou
+        // passkey) precisa dele para montar o `amr` inteiro.
+        ctx.session.put(MFA_PRIMARY_KEY, primary);
         return {
             kind: 'challenge',
             response: await render(ctx, 'mfa-challenge', {
@@ -971,7 +1006,7 @@ export default class AuthInteractionController {
             });
         }
         // Conta com segundo fator não termina o login só com o e-mail.
-        const magicGate = await this.secondFactorGate(ctx, cfg, acc.id, await service.interactions.details(ctx));
+        const magicGate = await this.secondFactorGate(ctx, cfg, acc.id, await service.interactions.details(ctx), 'email');
         if (magicGate.kind === 'challenge')
             return magicGate.response;
         await notifyLoginSuccess(ctx, cfg, {
@@ -1093,7 +1128,7 @@ export default class AuthInteractionController {
                 clientId,
             });
             // Conta com segundo fator não termina o login só com o código do e-mail.
-            const otpGate = await this.secondFactorGate(ctx, cfg, result.account.id, await service.interactions.details(ctx));
+            const otpGate = await this.secondFactorGate(ctx, cfg, result.account.id, await service.interactions.details(ctx), 'email');
             if (otpGate.kind === 'challenge')
                 return otpGate.response;
             await notifyLoginSuccess(ctx, cfg, {
@@ -1350,7 +1385,10 @@ export default class AuthInteractionController {
         }
         // Passkey OK: opcionalmente confia neste dispositivo (checkbox no challenge).
         await this.maybeTrustDevice(ctx, cfg, accountId);
-        ctx.session.forget(MFA_PENDING_KEY);
+        // Passkey como 2º fator (havia desafio pendente) ou passkey-first (não havia)?
+        // Lido ANTES de esquecer: é o que decide o amr abaixo.
+        const wasSecondFactor = ctx.session.get(MFA_PENDING_KEY) === accountId;
+        const { primary } = this.takeMfaPending(ctx);
         forgetLoginEmail(ctx);
         await notifyLoginSuccess(ctx, cfg, {
             accountId,
@@ -1358,9 +1396,12 @@ export default class AuthInteractionController {
             clientId,
             metadata: { mfa: 'webauthn' },
         });
-        // Step-up carimba acr/amr quando solicitado; senão a passkey conta como o fator
-        // forte do login (amr `['webauthn']`) — vale tanto p/ MFA quanto passkey-first.
-        await service.interactions.completeLogin(ctx, accountId, this.stepUpExtra(cfg, details, 'webauthn') ?? { amr: ['webauthn'] });
+        // 2º fator: amr = [primário, 'mfa', 'webauthn'] (+ acr no step-up), igual ao
+        // TOTP. Passkey-first: a passkey É o login (amr `['webauthn']`); o step-up
+        // carimba acr/amr quando solicitado.
+        await service.interactions.completeLogin(ctx, accountId, wasSecondFactor
+            ? this.mfaCompletion(cfg, details, primary, 'webauthn')
+            : (this.stepUpExtra(cfg, details, 'webauthn') ?? { amr: ['webauthn'] }));
     }
     /**
      * GET /auth/interaction/:uid/switch
@@ -1441,7 +1482,7 @@ export default class AuthInteractionController {
         // Senha trocada: limpa o step e finaliza o login.
         ctx.session.forget(PASSWORD_EXPIRED_KEY);
         // Verifica se precisa de MFA mesmo após a troca — mesma regra do resto.
-        const expiredGate = await this.secondFactorGate(ctx, cfg, accountId, details);
+        const expiredGate = await this.secondFactorGate(ctx, cfg, accountId, details, 'pwd');
         if (expiredGate.kind === 'challenge')
             return expiredGate.response;
         await service.interactions.completeLogin(ctx, accountId);