feat: add internal auth token to webhook calls

[heysarver]

Adds X-Internal-Auth-Token header to webhook requests when calling core-api internal endpoints.

Changes

• Read INTERNAL_AUTH_TOKEN from env var
• Include header only if token is set (dev compatibility)
• Applied to both email verification and OAuth signup webhook calls

Context

Required for core-api PR #19 (security audit) which adds validation of this token on the receiving end.

Deployment

After merge, set INTERNAL_AUTH_TOKEN env var in staging/prod (pulled from Bitwarden internal-auth-token field).

Summary by CodeRabbit

• New Features
  • Webhooks now support conditional internal authorization. Authentication credentials can be automatically included in webhook requests when configured.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Three webhook POST requests now conditionally include an internal authorization header (X-Internal-Auth-Token) when the corresponding environment variable is set. Changes affect afterEmailVerification and OAuth signup webhook invocations in the authentication module.

Changes

Cohort / File(s)	Summary
Webhook Authorization Headers src/lib/auth.ts	Added conditional X-Internal-Auth-Token header to three webhook POST requests (afterEmailVerification, OAuth signup paths) when INTERNAL_AUTH_TOKEN environment variable is defined.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 A token so secret, tucked in the air,
Now guards three pathways with utmost care,
When webhooks dance and users verify,
Authorization whispers as messages fly! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly and clearly summarizes the main change: adding an internal authentication token to webhook calls, which matches the core objective of the PR.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch henry

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@src/lib/auth.ts`:
- Around line 139-144: Only attach the X-Internal-Auth-Token header when the
target webhook URL is trusted: parse the webhook URL (e.g., the
WELCOME_EMAIL_WEBHOOK_URL or the url variable used where headers are built),
validate its hostname against an allowlist provided via an env var (e.g.,
INTERNAL_AUTH_TRUSTED_HOSTS as a comma-separated list) or a simple internal-host
check, and only then include process.env.INTERNAL_AUTH_TOKEN in the headers;
otherwise omit the header. Implement this check where headers are constructed
(the code that currently builds the headers object with 'Content-Type' and
optionally 'X-Internal-Auth-Token') so the header injection is gated by the
validated hostname.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Scope the internal token to trusted webhook URLs.

Right now the token is attached whenever INTERNAL_AUTH_TOKEN is set, regardless of the webhook target. If WELCOME_EMAIL_WEBHOOK_URL is misconfigured or redirected to an external host, this leaks the internal token. Consider gating header injection to an allowlist of internal hosts (e.g., from an env var) or validating the URL before attaching the header.

🤖 Prompt for AI Agents

In `@src/lib/auth.ts` around lines 139 - 144, Only attach the
X-Internal-Auth-Token header when the target webhook URL is trusted: parse the
webhook URL (e.g., the WELCOME_EMAIL_WEBHOOK_URL or the url variable used where
headers are built), validate its hostname against an allowlist provided via an
env var (e.g., INTERNAL_AUTH_TRUSTED_HOSTS as a comma-separated list) or a
simple internal-host check, and only then include
process.env.INTERNAL_AUTH_TOKEN in the headers; otherwise omit the header.
Implement this check where headers are constructed (the code that currently
builds the headers object with 'Content-Type' and optionally
'X-Internal-Auth-Token') so the header injection is gated by the validated
hostname.