Add support for dynamic Bearer token via custom JS module

[stepan-prokipchyn-vitech]

Motivation:
In real life bearer token is temporary and generated via API call. Setting it each time in MCP configuration is inconvenient. The aim of this new feature is to allow to provide a function in MCP configuration that the server will use to acquire a new token when it is needed. This function can implement custom authentication mechanism.

[stepan-prokipchyn-vitech]

@dkmaker is there a way this can be merged (even if with some modification). We really need a way to implement authentication and some other improvements later. If you don't have a capacity to work on this, we can publish a forked version

[dkmaker]

I will review it today seems like a cool addition!

[dkmaker]

@stepan-prokipchyn-vitech

PR Review: Add support for dynamic Bearer token via custom JS module

Thanks for this contribution! This is a useful feature that addresses a real need for dynamic token acquisition. The implementation is generally solid with good JWT handling and proper caching/deduplication.

Issues to Address

1. Missing 401 retry logic (Important)

The TokenProvider.invalidate() method exists but is never called anywhere in the code. If a request fails with a 401 (token expired unexpectedly or server invalidated it early), the stale token will continue to be used for subsequent requests.

Suggested fix: Add retry logic that invalidates the token and retries once on 401:

// After making the request, check for 401 and retry with fresh token
if (response.status === 401 && this.tokenProvider) {
  this.tokenProvider.invalidate();
  const freshToken = await this.tokenProvider.getToken(true);
  config.headers = {
    ...config.headers,
    'Authorization': `Bearer ${freshToken}`
  };
  // Retry the request once
  response = await this.axiosInstance.request(config);
}

2. Security documentation

Loading and executing user-provided JavaScript modules is a trust boundary. Consider adding a note to the README/docs warning users to only use trusted modules, e.g.:

Security Note: The AUTH_TOKEN_MODULE executes arbitrary JavaScript code. Only use modules from trusted sources.

Minor Items

3. Whitespace changes in README

Lines 1-2 show whitespace-only changes (possibly CRLF line ending differences). Consider reverting these to keep the diff clean.

4. Optional: TTL for non-JWT tokens

For tokens without an exp claim, the token is cached indefinitely. An optional AUTH_TOKEN_TTL_SECONDS environment variable could provide a fallback refresh interval for non-JWT tokens.

5. Optional: Example auth modules

It would be great to include an auth-modules/ folder with example modules that users can reference:

• A basic template showing the expected function signature
• One or two real-world examples (e.g., OAuth client credentials flow, or a well-known service like Auth0/Keycloak)

This would help users understand how to implement their own modules and serve as working reference implementations. If you have any examples from your own use case that could be generalized, that would be very helpful!

---

Overall this is good work - the TokenProvider class is well-designed with proper inflight request deduplication and JWT expiry detection. Happy to approve once the 401 retry logic is added!

[stepan-prokipchyn-vitech]

@dkmaker thank you for your review. I've just added yet another commit - sorry for late update, I made these changes earlier, but wasn't sure if you still monitor this project. These changes are more controversial because they add yet another tool parameter so I'm open to you suggestion on this too. I'll review your current suggestions over the weekend. Thanks again.

[stepan-prokipchyn-vitech]

The current implementation works fine and my Claude Code agent is able to use default user and then switch to another user (one he create beforehand) and then switch back to default