PR 描述

Context

The API previously supported JWT authentication only. We now need to support API key–based integrations while protecting authentication endpoints and downstream services from excessive traffic and abuse.

What changed

Authentication middleware

• Refactored the auth middleware to support:
  • JWT bearer tokens
  • API keys
• Added credential detection and validation for both authentication methods.
• Preserved existing JWT behavior and error handling.
• Standardized the authenticated request context across JWT and API key flows.

Rate limiting

• Added request rate limiting to protected API routes.
• Returns 429 Too Many Requests when limits are exceeded.
• Added rate-limit response headers where applicable.
• Made limits configurable by environment.

Tests and configuration

• Added coverage for valid, invalid, missing, and expired credentials.
• Added tests for rate-limit enforcement and reset behavior.
• Documented the required API key and rate-limit configuration.

How to test

1. Start the application with JWT, API key, and rate-limit configuration enabled.
2. Call a protected endpoint with a valid JWT and verify the request succeeds.
3. Call the same endpoint with an expired or invalid JWT and verify it is rejected.
4. Call the endpoint with a valid API key and verify the request succeeds.
5. Call the endpoint with an invalid API key and verify it is rejected.
6. Call the endpoint without credentials and verify it returns the expected authentication error.
7. Send requests until the configured rate limit is exceeded.
8. Verify excess requests return 429 Too Many Requests with the expected headers.
9. Wait for the rate-limit window to reset and verify requests succeed again.
10. Run the automated test suite and confirm all authentication and rate-limiting tests pass.

Risk assessment

Risk level: Medium

• Authentication middleware changes affect all protected routes.
• Incorrect configuration could reject valid clients or