@adonis-agora/authkit-server 0.68.4 → 0.70.0

package/build/src/host/register_auth_host.js

@@ -7,6 +7,7 @@ import { ACCOUNT_SESSION_KEY } from './account_session_key.js';
 import { adminApiGuard } from './admin_api/admin_api_guard.js';
 import { normalizeAdminApiPrefix, normalizeAdminPrefix, setAdminApiPrefix, setAdminPrefix, } from './admin_prefix.js';
 import { getAuthHostConfig, markAuthHostAutoMounted, wasAuthHostAutoMounted, } from './auth_host_config.js';
+import { ensureConsoleSession } from './idp_session_bridge.js';
 import { createAuthThrottles } from './rate_limit.js';
 import { resolveRuntimeSettings } from './runtime_settings.js';
 import { resolveEffectiveSessionPolicy } from './runtime_toggles.js';
@@ -113,7 +114,8 @@ function buildLoginRedirect(ctx, extra) {
  * /account/mfa acessíveis sem sessão.
  */
 const accountGuard = async (ctx, next) => {
-    if (!ctx.session?.get(ACCOUNT_SESSION_KEY)) {
+    // Sessão do console — ou, com `accountSession.acceptIdpSession`, a do IdP (SSO).
+    if (!(await ensureConsoleSession(ctx))) {
         return ctx.response.redirect(buildLoginRedirect(ctx));
     }
     // Idle timeout: encerra e redireciona com query param de motivo.
@@ -143,6 +145,8 @@ export const adminGuard = async (ctx, next) => {
     if (!cfg.admin.enabled) {
         return ctx.response.notFound();
     }
+    // Com `accountSession.acceptIdpSession`, a sessão do IdP também abre o console.
+    await ensureConsoleSession(ctx);
     const accountId = ctx.session?.get(ACCOUNT_SESSION_KEY);
     if (!accountId) {
         // `/account/login` é sempre o login da conta — NÃO muda com o prefixo admin.
@@ -207,6 +211,10 @@ const C = {
     apiKeys: () => import('./admin_api/api_keys_controller.js'),
     // Account self-service JSON API (session-authed, under /account/api/*).
     accountApi: () => import('./account_api/account_api_controller.js'),
+    // Espelhos JSON das ESCRITAS de org e do segundo fator — mesmos guards e
+    // mesma política do console HTML, resposta em JSON (ver os docblocks deles).
+    accountOrgsApi: () => import('./account_api/account_orgs_api_controller.js'),
+    accountMfaApi: () => import('./account_api/account_mfa_api_controller.js'),
     // API headless (Clerk-style) — host-session-authed via `headless.resolveAccountId`.
     headlessLoginMethods: () => import('./controllers/headless_login_methods_controller.js'),
 };
@@ -649,6 +657,53 @@ export function registerAuthHost(router, opts = {}) {
         router.get(`${apiBase}/orgs`, [C.accountApi, 'listOrgs']);
         router.get(`${apiBase}/orgs/invitations`, [C.accountApi, 'listOrgInvitations']);
         router.get(`${apiBase}/orgs/:id`, [C.accountApi, 'showOrg']);
+        // ─── Orgs: ESCRITA em JSON (espelho dos POSTs de formulário) ─────────
+        // SEMPRE montadas, como as leituras JSON logo acima — e NÃO amarradas ao
+        // `mountOrgs` da TELA. A tela é a UI do console; `/account/api/*` é a
+        // superfície de máquina, e quem desliga a tela é justamente o host que
+        // desenha as próprias telas e mais precisa destes endpoints. Amarrar as
+        // duas coisas tornaria o modo headless inalcançável.
+        //
+        // Desligar a tela não afrouxa nada: o que decide quem pode o quê aqui é o
+        // `accountGuard` + capability-probe do store + política efetiva
+        // (`allowSelfCreate` continua `false` por default) + papel na org — os
+        // mesmos gates do formulário, nunca a presença de uma rota HTML.
+        // ⚠️ ORDER MATTERS, de novo: segmento fixo antes de paramétrico.
+        router.post(`${apiBase}/orgs`, [C.accountOrgsApi, 'createOrg']);
+        router.post(`${apiBase}/orgs/deactivate`, [C.accountOrgsApi, 'deactivateOrg']);
+        router.post(`${apiBase}/orgs/invitations/:token/accept`, [
+            C.accountOrgsApi,
+            'acceptInvitation',
+        ]);
+        router.post(`${apiBase}/orgs/:id/activate`, [C.accountOrgsApi, 'activateOrg']);
+        router.post(`${apiBase}/orgs/:id/leave`, [C.accountOrgsApi, 'leaveOrg']);
+        router.post(`${apiBase}/orgs/:id/invitations`, [C.accountOrgsApi, 'inviteMember']);
+        router.delete(`${apiBase}/orgs/:id/invitations/:invId`, [
+            C.accountOrgsApi,
+            'revokeInvitation',
+        ]);
+        router.patch(`${apiBase}/orgs/:id/members/:accountId`, [
+            C.accountOrgsApi,
+            'updateMemberRole',
+        ]);
+        router.delete(`${apiBase}/orgs/:id/members/:accountId`, [C.accountOrgsApi, 'removeMember']);
+        // ─── Segundo fator em JSON (espelho do console de MFA) ───────────────
+        // Mesma decisão das de org: superfície de máquina, montada sempre. Sem a
+        // capacidade de MFA no store, cada handler responde 422
+        // `capability_unsupported` — capability-probed, como o resto do
+        // `/account/api/*`.
+        router.post(`${apiBase}/mfa/totp/enroll`, [C.accountMfaApi, 'enrollTotp']);
+        // THROTTLE no confirm: o código TOTP é adivinhável (6 dígitos), e o
+        // `accountGuard` sozinho só exige uma sessão viva — que quem está
+        // tentando adivinhar tem. Bucket de SUDO (por IP): mesma natureza —
+        // usuário autenticado reprovando um fator —, contagem separada do login.
+        // O form clássico não tem isto; o JSON fica MAIS apertado, que é a única
+        // direção em que os dois caminhos podem divergir.
+        withSudo(router.post(`${apiBase}/mfa/totp/confirm`, [C.accountMfaApi, 'confirmTotp']));
+        router.post(`${apiBase}/mfa/totp/disable`, [C.accountMfaApi, 'disableTotp']);
+        router.post(`${apiBase}/mfa/recovery-codes`, [C.accountMfaApi, 'regenerateRecoveryCodes']);
+        router.post(`${apiBase}/mfa/passkeys/options`, [C.accountMfaApi, 'passkeyRegisterOptions']);
+        router.post(`${apiBase}/mfa/passkeys/verify`, [C.accountMfaApi, 'passkeyRegisterVerify']);
     })
         .use([accountGuard]);
     // API headless (Clerk-style) — montada fora do `accountGuard` (não depende da

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

@@ -762,11 +762,11 @@ export declare function resolveEffectiveRolesCatalog(settings: SettingsCapabilit
  *
  * Invariante mantida: 'owner' é sempre incluído na lista de roles (governance).
  *
- * @param settings - SettingsCapability
+ * @param settings - SettingsCapability, ou null (runtime settings indisponível → config/defaults)
  * @param configDefault - defaults estáticos do config do host
  * @param orgId - opcional; quando fornecido, tenta settings da org antes do global
  */
-export declare function resolveEffectiveOrganizationsPolicy(settings: SettingsCapability, configDefault?: OrganizationsPolicyConfigDefaults, orgId?: string | null): Promise<ResolvedOrganizationsPolicySetting>;
+export declare function resolveEffectiveOrganizationsPolicy(settings: SettingsCapability | null, configDefault?: OrganizationsPolicyConfigDefaults, orgId?: string | null): Promise<ResolvedOrganizationsPolicySetting>;
 /**
  * Resolve o CATÁLOGO efetivo de roles de org (lista de roles permitidas),
  * garantindo a invariante de governance: `owner` está sempre presente.

package/build/src/host/runtime_toggles.js

@@ -737,7 +737,7 @@ export async function resolveEffectiveRolesCatalog(settings, orgId) {
  *
  * Invariante mantida: 'owner' é sempre incluído na lista de roles (governance).
  *
- * @param settings - SettingsCapability
+ * @param settings - SettingsCapability, ou null (runtime settings indisponível → config/defaults)
  * @param configDefault - defaults estáticos do config do host
  * @param orgId - opcional; quando fornecido, tenta settings da org antes do global
  */
@@ -769,6 +769,8 @@ export async function resolveEffectiveOrganizationsPolicy(settings, configDefaul
             roles,
         };
     }
+    if (!settings)
+        return defaults;
     try {
         // Resolução org → global → defaults
         if (orgId) {

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

@@ -108,6 +108,23 @@ export declare function markSudo(ctx: HttpContext): void;
  * @returns `true` se o sudo está ativo (dentro da graça); `false` caso contrário.
  */
 export declare function isSudoActive(ctx: HttpContext, graceMinutes: number): boolean;
+/**
+ * A DECISÃO de sudo, sem efeito colateral nenhum na resposta: `true` quando a
+ * requisição pode seguir, `false` quando o usuário precisa reconfirmar a
+ * identidade.
+ *
+ * Existe porque há DUAS formas de recusar a mesma coisa. O console HTML
+ * redireciona para `/account/confirm` (`requireSudo`); o espelho JSON de
+ * `/account/api/*` responde `403 { error: { code: 'sudo_required' } }`, porque
+ * uma SPA que recebe uma página de login onde esperava JSON não tem como
+ * reagir. A POLÍTICA — toggle `sudo_mode`, janela de graça, vinculação à conta,
+ * fail-safe da setting e fail-closed da marca — tem de ser UMA só: duas cópias
+ * dela são como o caminho JSON acaba mais frouxo que o formulário.
+ *
+ * Toda a discussão de fail-safe × fail-closed do {@link requireSudo} vale aqui
+ * sem mudança: é literalmente o mesmo código.
+ */
+export declare function isSudoSatisfied(ctx: HttpContext, settings: SettingsCapability | null): Promise<boolean>;
 /**
  * Guard de sudo mode. Verifica se a confirmação de identidade está ativa e
  * dentro da janela de graça. Se estiver, retorna `true`. Se não, redireciona

package/build/src/host/sudo_mode.js

@@ -146,6 +146,36 @@ export function isSudoActive(ctx, graceMinutes) {
     const graceMs = graceMinutes * 60 * 1000;
     return Date.now() - sudoAt <= graceMs;
 }
+/**
+ * A DECISÃO de sudo, sem efeito colateral nenhum na resposta: `true` quando a
+ * requisição pode seguir, `false` quando o usuário precisa reconfirmar a
+ * identidade.
+ *
+ * Existe porque há DUAS formas de recusar a mesma coisa. O console HTML
+ * redireciona para `/account/confirm` (`requireSudo`); o espelho JSON de
+ * `/account/api/*` responde `403 { error: { code: 'sudo_required' } }`, porque
+ * uma SPA que recebe uma página de login onde esperava JSON não tem como
+ * reagir. A POLÍTICA — toggle `sudo_mode`, janela de graça, vinculação à conta,
+ * fail-safe da setting e fail-closed da marca — tem de ser UMA só: duas cópias
+ * dela são como o caminho JSON acaba mais frouxo que o formulário.
+ *
+ * Toda a discussão de fail-safe × fail-closed do {@link requireSudo} vale aqui
+ * sem mudança: é literalmente o mesmo código.
+ */
+export async function isSudoSatisfied(ctx, settings) {
+    try {
+        const cfg = settings ? await resolveEffectiveSudoMode(settings) : SUDO_MODE_DEFAULTS;
+        if (!cfg.enabled)
+            return true;
+        return isSudoActive(ctx, cfg.graceMinutes);
+    }
+    catch {
+        // FAIL-SAFE: erro ao resolver a setting → deixa passar. Disponibilidade, não
+        // identidade — ver o docblock de `requireSudo` para o porquê de isto NÃO
+        // contradizer o fail-closed de `isSudoActive`.
+        return true;
+    }
+}
 /**
  * Guard de sudo mode. Verifica se a confirmação de identidade está ativa e
  * dentro da janela de graça. Se estiver, retorna `true`. Se não, redireciona
@@ -202,19 +232,8 @@ export function isSudoActive(ctx, graceMinutes) {
  * postura é fail-closed de novo.
  */
 export async function requireSudo(ctx, settings) {
-    try {
-        const cfg = settings ? await resolveEffectiveSudoMode(settings) : SUDO_MODE_DEFAULTS;
-        if (!cfg.enabled)
-            return true;
-        if (isSudoActive(ctx, cfg.graceMinutes))
-            return true;
-    }
-    catch {
-        // FAIL-SAFE: erro ao resolver a setting → deixa passar. Disponibilidade, não
-        // identidade — ver o docblock acima para o porquê de isto NÃO contradizer o
-        // fail-closed de `isSudoActive`.
+    if (await isSudoSatisfied(ctx, settings))
         return true;
-    }
     // Fora da graça: redireciona para confirmação.
     const rawUrl = ctx.request.url?.() ?? '';
     const qs = ctx.request.parsedUrl?.search ?? '';