@rodit/rodit-auth-be 9.11.20 → 9.13.0

package/CHANGELOG.md

@@ -2,6 +2,106 @@
 
 All notable changes to `@rodit/rodit-auth-be` are documented here.
 
+## [9.13.0] — 2026-07-15
+
+### Added
+
+- **Federated login across APIs in the same SR/CR family.** A client RODiT
+  issued for API A can log into API B via
+  `login_server({ apiEndpoint: '<federated URL>' })`. Mutual auth remains
+  optional; federation is login → remint a local JWT (foreign JWTs are not
+  accepted without re-login).
+- **JWT claim `rodit_subjectuniqueidentifier_url` (always present).** Same
+  unset-as-`null` rule as `config_*` in 9.12:
+  - Same-API login: claim is `null`; `iss` = receiving server URL
+  - Federated login: claim = federated API URL; `iss` = client home
+    `subjectuniqueidentifier_url`
+  - Server validation treats non-empty claim strings as federated JWTs
+    (`isNonEmptyUrlClaim`); renewal always copies/normalizes to `null` or the
+    URL (9.12 tokens without the claim renew into `null`)
+- **Client MITM check.** After crypto validation, `login_server` verifies that
+  a federated JWT's `rodit_subjectuniqueidentifier_url` matches the intended
+  `apiEndpoint` and that `iss` matches the client home URL. Failures:
+  `FEDERATED_ISSUER_MISSING`, `FEDERATED_ISSUER_MISMATCH`.
+- **Exported helpers:** `normalizeUrlWithoutPort`, `isNonEmptyUrlClaim`,
+  `isFederatedRoditLogin`, `validateFederatedLoginTarget`.
+
+## [9.12.0] — 2026-07-02
+
+### Fixed
+
+- **Multi-peer inbound webhook verification.** Inbound webhook signatures were
+  verified against `stateManager.getPeerBase64urlJwkPublicKey()`, a single
+  mutable "current peer" slot. When an agent was connected to several peers the
+  slot was clobbered by the most recent peer, so webhooks from other senders
+  (including the central API) failed with a false `401`
+  `WEBHOOK_SIGNATURE_INVALID` / `PEER_KEY_UNAVAILABLE`.
+
+### Added
+
+- **Self-identifying webhooks.** The signer's Ed25519 public key now travels
+  with each webhook, so verification no longer depends on a shared "current
+  peer" slot and is correct when connected to many peers at once:
+  - `send_webhook` advertises the signer identity via `X-Rodit-Public-Key`,
+    `X-Rodit-Implicit-Account` (hex of the signing key), and `X-Rodit-Token-Id`.
+  - `webhookHandler.extractWebhookSignerKey(headers)` reads that key directly
+    (implicit account is authoritative on its own; a raw advertised key must
+    agree with it). Exported from the package root as `extractWebhookSignerKey`.
+- **Signer ↔ session authorization gate.** A valid signature only proves the
+  sender holds the advertised private key; it does not prove that identity is a
+  peer we established a session with. `createWebhookAuthenticationMiddleware`
+  now enforces, after the signature verifies, that the (signed) `session_id`
+  maps to a live session whose `ownerId` equals the verified signer's implicit
+  account. New rejections: `401 WEBHOOK_SESSION_REQUIRED`,
+  `401 WEBHOOK_SESSION_INVALID`, `403 WEBHOOK_SIGNER_SESSION_MISMATCH`
+  (bypassed only under `NODE_ENV=test` or
+  `SECURITY_OPTIONS.BYPASS_WEBHOOK_VERIFICATION`). The validated binding is
+  exposed as `req.webhook_session`, `req.webhook_session_id`, and
+  `req.webhook_signer_implicit_account`.
+- **Webhook ↔ session correlation.** `send_webhook` stamps the originating
+  session id into the **signed** payload (`session_id`) so receivers can link an
+  inbound webhook to the session opened at login:
+  - `extractWebhookSessionId({ headers, rawPayload, parsedBody })` returns the
+    session id (signed payload authoritative, `X-Rodit-Session-Id` header as
+    fallback). Exported from the package root and from `webhookHandler`.
+  - `createPublicKeyMiddleware` sets `req.webhook_session_id` for downstream
+    handlers.
+  - The session id is resolved without requiring a request context: it falls
+    back to **session storage** (the SessionManager singleton, in-memory by
+    default) via `findSessionsByRoditId(options.sessionRoditId)`, so a JWT issuer
+    (`login_client`) can stamp the shared session id for out-of-band webhooks.
+  - `RoditClient.sendWebhook` / `sendWebhookToEndpoint` / `sendWakeHook` /
+    `sendAgentHook` accept an `options` argument (`sessionId`, `sessionRoditId`)
+    and default `sessionId` to the client's own `this.sessionId` (set at
+    `login_server`), so a peer that initiated the login stamps its session
+    automatically.
+- **Client-side session recording (symmetric session store).** The
+  `SessionManager` facility used by servers to track client sessions is now also
+  used by clients to record the sessions they open:
+  - `SessionManager.recordSession({ id, roditId, ... })` stores an
+    externally-issued session under its own id (idempotent), tagged
+    `origin: "client"`. `createSession` now tags issued sessions
+    `origin: "server"`.
+  - `SessionManager.hasSession(id)` quietly reports whether an id is a known,
+    live session (no warn logs, no lastAccessedAt bump); `forgetSession(id)`
+    removes one.
+  - `RoditClient.login_server` records each opened session keyed by the server's
+    roditId, so a client connected to many servers can cross-reference an inbound
+    webhook's `session_id` to a live session (multi-peer safe, unlike the single
+    `this.sessionId` slot). `clearSession` forgets it.
+  - `RoditClient.isKnownSession(id)` cross-references a webhook's session id
+    against the client's open sessions.
+  - Issuer-side webhook session lookup only considers `origin !== "client"`
+    sessions, so mutual peers don't cross-stamp.
+
+### Changed
+
+- **`createPublicKeyMiddleware`** extracts the verification key from the webhook
+  itself (`extractWebhookSignerKey`) instead of the mutable
+  `stateManager.getPeerBase64urlJwkPublicKey()` slot, and attaches
+  `req.webhook_session_id`. Authentication (key from the webhook) and
+  authorization (binding to a session) are now cleanly separated.
+
 ## [8.0.0] — 2026-05-02
 
 ### Breaking