v2.7.0

Added

• onLogin hooks receive authenticated-source evidence (oauthUser.authEvidence): a frozen, hook-only snapshot exposing the plugin's own trust determination — emailProvenance ('signed-oidc' / 'github-authenticated' / 'unauthenticated', normalized), emailAuthenticated, signatureVerified, issuerValidated, emailVerified, email (populated regardless of trust — verified only when emailAuthenticated is true), and the validated idTokenIssuer / idTokenSubject. A hook that adopts an existing account should base the decision on authEvidence.emailAuthenticated (resolve from authEvidence.email, or bind on the idTokenIssuer+idTokenSubject pair), not on the spoofable emailVerified. The new OAuthAuthEvidence and EmailProvenance types are exported. Does not change the built-in account-adoption gate.

Changed

• redirectUri is required; the http://localhost:9926/oauth fallback is removed (#208): a missing, empty, or unresolved-${VAR} redirectUri (plugin-level or per-provider) now fails at startup naming the key, instead of silently sending a loopback redirect that some IdPs accept and that would hand the authorization code to whatever is listening on the end user's own machine. The provider segment is appended for …/oauth, …/oauth/callback (with or without a trailing slash) and a query string is preserved. Upgrade note: any app that relied on the default, including local-dev setups, must set redirectUri to its public origin plus /oauth before the plugin will load.
• MCP refresh-token families minted before this version are retired at their next refresh (#229): a refresh presenting a valid token for a family created by an earlier version is rejected with invalid_grant, the family is revoked, and an oauth.mcp.token.retired audit event is emitted; the client re-authorizes once. New families carry their provenance in the family_id (p1- prefix), which rotation preserves, so a mixed-version rollout cannot strip it. Access tokens already issued keep working until they expire. Upgrade note: every MCP client holding a pre-upgrade refresh token re-authorizes once at its next refresh; after a rollback, only families minted while rolled back re-authorize after re-upgrading. Browser login sessions are unaffected.

Fixed

• A declared mcp.signingKeyPem that cannot be used now fails at startup (#221): when mcp.enabled is true, an empty value, an unresolved ${VAR} placeholder, an unparseable PEM, or an RSA key under 2048 bits (which jsonwebtoken refuses at signing time) throws naming the key, instead of silently self-generating a key or returning 500 at token mint. Omitting the key still self-generates, and removing it on a live config reload still switches to self-generation. Upgrade note: the startup throw stops the whole plugin from loading, so on an instance with an unusable declared key, browser OAuth login is down as well as MCP token grants until the key is fixed or removed (a bad value applied by live reload is rejected and the previous config keeps serving; only a restart with it fails).