Hardening follow-ups from PR #526 review (no defect fixes):
- DO1: add auth.controller.spec tests for the collab-token handler, the
arm-seam of the anti-laundering defense. Assert getCollabToken is invoked
with { apiKeyId } only when the SIGNED req.raw marks an api_key principal,
and undefined otherwise (session, missing apiKeyId, or a spoofed body).
Verified non-vacuous: nulling the ternary reddens the ARMED test.
- DO2: document the API_KEYS_ENABLED kill-switch in .env.example next to the
other feature flags (default ON; strict true/false; OFF denies api-key auth
and 404s the management endpoints).
- DO3: remove dead bindAccessJwtVerifier (+ its now-orphaned AccessJwtVerifier
interface and its dedicated spec block); prod switched to
bindMcpBearerVerifier. verifyBearerAccess is retained (still used).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
api_key-принципал стал полноправным REST-принципалом → мог начеканить 24-ч
COLLAB-токен, который AuthenticationExtension не сверял с api_keys, и ревокация
не доставала websocket-редактирование. Блокировать /collab-token для api_key
нельзя (это правки агентов). Решение fail-closed:
- JwtCollabPayload расширен полем principal ('session'|'api_key') + apiKeyId.
generateCollabToken штампует его в КАЖДЫЙ токен: 'api_key'+apiKeyId, когда
чеканит api-key-принципал (внешний MCP-агент), иначе 'session'. Дискриминатор
ключуется на ОРИГИНЕ (наличии api-key), НЕ на actor:'agent' — внутренний
session-backed AI-агент остаётся 'session' и на no-check пути.
- /auth/collab-token читает подписью-выведенные req.raw.authType/apiKeyId
(не тело) и прокидывает origin через getCollabToken → generateCollabToken.
- doAuthenticate: при principal='api_key' на connect прогоняет
ApiKeyService.validate (отозванный ключ → новых collab-подключений нет; инфра
пробрасывается). api_key без apiKeyId — reject. Claimless-токен доверяется
только В ПРЕДЕЛАХ 24-ч grace-окна роллаута (легаси session-токен, api_key его
начеканить не мог); после окна всякий валидный токен обязан нести
дискриминатор, поэтому claimless — баг и отвергается (не молча-доверие 24ч).
CollaborationModule импортирует ApiKeyModule.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
/mcp-Bearer больше не пинит тип к ACCESS. Новый framework-free примитив
verifyMcpBearer верифицирует подпись ОДИН раз (bindMcpBearerVerifier пинит
allowlist {ACCESS, API_KEY}) и роутит:
- API_KEY → сперва биндинг к воркспейсу инстанса (чужой воркспейс — отказ), затем
общий row-check ApiKeyService.validate. HMAC-верификация (микросекунды) вместо
bcrypt, это НЕ попытка логина — Basic-путь и анти-брутфорс-лимитер не
затрагиваются (фикс удушения параллельных чтений агентов).
- ACCESS → прежний verifyBearerAccess (session-active + not-disabled), которому
передаётся замыкание над уже проверенным payload, так что «проверить один раз»
и «helper без изменений» сосуществуют.
Bearer-нога resolveMcpSessionConfig униформизирована: любой отказ авторизации →
единый generic-401 (анти-enumeration, класс отказа не течёт в тело), а
непредвиденная (инфра) ошибка ПРОБРАСЫВАЕТСЯ (→5xx), не маскируется под 401.
McpService получает ApiKeyService; McpModule импортирует ApiKeyModule.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Форк не несёт EE-модуль ee/api-key, поэтому api_key-токен сегодня отвергается на
любом /api/*. Вводим core-модуль:
- ApiKeyRepo (kysely): insert/findById/findByCreator/findAllInWorkspace/
softDelete/touchLastUsed, фильтр deleted_at IS NULL.
- ApiKeyService.create — mint-then-insert: сперва uuid7 id, затем чеканка JWT
без exp, затем строка (сбой чеканки → строки нет; потерянный ответ →
осиротевшая строка видна в list и самолечится). Токен отдаётся один раз, в
таблице не хранится.
- ApiKeyService.validate — единый валидатор для jwt.strategy И /mcp. Владелец
истины о сроке/отзыве — строка api_keys, не JWT. Любой определённый негатив
(нет строки / expired / disabled / workspace mismatch / kill-switch off) →
единый bare-401 (анти-enumeration); инфра-ошибка пробрасывается (→5xx), не
маскируется. Без кэша — немедленная ревокация. last_used_at троттлится 1ч,
fire-and-forget.
- REST create/list/revoke: create — self + UserThrottlerGuard; list/revoke —
admin (CASL Manage на API) видит/отзывает все ключи воркспейса, член — только
свои. api_key-принципал отвергается на всех трёх (токен не управляет
токенами — GitHub-PAT-семантика). Аудит API_KEY_CREATED/DELETED + структурный
лог с apiKeyId и IP.
- jwt.strategy: прямой вызов ApiKeyService.validate вместо динамического
EE-require; штампует req.raw.authType='api_key' и apiKeyId для гварда выше.
- Kill-switch API_KEYS_ENABLED: дефолт ON (деплой без переменной не убивает
агентов), строгий парс @IsIn(['true','false']) (=0/=off падают на boot, а не
молча значат «включено»), boot-лог состояния. off → validate deny и
эндпоинты 404.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
TokenService получает примитив type-routing`verifyJwtOneOf(token, allowed[])`:
подпись проверяется один раз, тип обязан входить в явный allowlist, иначе — тот
же generic-throw, что и у verifyJwt. Нужен для /mcp-Bearer, который принимает и
ACCESS, и API_KEY на одном слоте, но без переиспользуемого footgun'а
«verify-and-return-any-type».
generateApiToken теперь чеканит api-key токен БЕЗ клейма exp. Единственный
источник истины о сроке/отзыве ключа — строка api_keys (проверяется на каждом
запросе), не JWT. Общий jwtService зарегистрирован с глобальным
signOptions.expiresIn ('90d'), который мержится в любой sign() — даже
sign(payload, {}) — а {expiresIn: undefined} бросает; поэтому «бессрочный» ключ
через общий signer молча получал бы exp=now+90d. Чеканка идёт через выделенный
signer без expiresIn (issuer 'Docmost' для паритета клеймов). Живой баг
подтверждён эмпирически и покрыт тестом.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
agent_coder