bug: rm refresh endpoint and require auth

[chloebyun-wd]

Original attack chain vs. current fix

Step	Attack	Before fix	After fix
1	Attacker calls POST /refresh/:id with no auth	Whitelisted → middleware calls next() → handler runs	Still whitelisted → middleware calls next() → handler checks x-flowise-internal-key header
2	Handler processes request	Decrypts credential, calls OAuth provider, returns access_token	providedKey is undefined → returns 401 immediately
3	Token in response	tokenInfo: { ...tokenData } leaks access_token	Response only contain has_new_refresh_token and expires_at

The Docker validation test (POST /refresh/fake-uuid returning {"message":"Credential not found"} instead of 401) would now return {"success":false,"message":"Unauthorized"} — a 401 before the credential lookup even happens.

All five reported impacts mitigated

Impact	Mitigated by
OAuth2 access token theft	Handler rejects requests without valid x-flowise-internal-key → attacker gets 401 before any credential is touched
Third-party account access	Same — no token is ever returned to an unauthenticated caller
Client secret transmission	Same — the OAuth provider refresh call never executes
Token leakage in response	Even for legitimate callers, access_token/refresh_token are stripped from the response body
DoS via refresh token quota	Auth check prevents unauthorized refresh attempts

Defense in depth layers

1. Handler-level auth with crypto.timingSafeEqual — primary gate; prevents timing side-channel attacks on key comparison
2. Token stripping from response — fallback; limits damage if auth is ever bypassed
3. Key resolved via getEncryptionKey() — supports env var, AWS Secrets Manager, and key file (no single-point-of-failure)
4. Key cached in memory — avoids file I/O or AWS API calls on every refresh request
5. Key threaded via options.internalRefreshKey — server resolves the key once and passes it through the flow execution pipeline, so components don't depend on process.env directly

Architectural trade-off

The endpoint remains in WHITELIST_URLS so the global auth middleware doesn't block internal server-to-server calls (which carry no JWT/API key). This is acceptable because the handler's own auth check runs first, using the server's encryption key — which an external attacker cannot know.

[gemini-code-assist]

Code Review

This pull request implements an internal authentication mechanism for OAuth2 token refresh requests by introducing an 'x-flowise-internal-key' header and propagating it through the execution flow. It also enhances security by omitting sensitive token data from the refresh response. Feedback suggests addressing a potential runtime error in the timing-safe comparison logic and removing the local encryption key cache to prevent consistency issues during key rotation.