bug: remove refresh endpoint and require auth

[chloebyun-wd]

No description provided.

[gemini-code-assist]

Code Review

This pull request secures the OAuth2 token refresh endpoint by adding an internal header authentication check and removing sensitive token data from the response. However, the implementation should use the getEncryptionKey utility for the authentication header to ensure compatibility with various secret storage backends. Additionally, the endpoint must remain in the whitelist to prevent global authentication middleware from blocking internal requests before the header check is performed.

[gemini-code-assist]

The internal authentication header should use the actual encryption key retrieved via getEncryptionKey(). Relying solely on process.env.FLOWISE_SECRETKEY_OVERWRITE will cause authentication failures (401 Unauthorized) if the key is stored in a file or AWS Secrets Manager, as getEncryptionKey() handles these fallbacks while the current implementation defaults to an empty string when the environment variable is unset.

                            'x-flowise-internal-key': await getEncryptionKey()

References

1. When a feature requires a specific configuration like an API key or secret, it is preferable to use the established retrieval mechanism that handles environment fallbacks or throws errors if missing, rather than relying on a single environment variable.

[gemini-code-assist]

Removing /api/v1/oauth2-credential/refresh from WHITELIST_URLS will likely break the internal token refresh mechanism. The global authentication middleware typically intercepts requests to non-whitelisted endpoints. Since the server-side call in refreshOAuth2Token does not include user session cookies or an API key, it will be rejected with a 401 error before reaching the route-level internal key check. To allow internal authentication while preventing public access, this endpoint should remain in the whitelist.

References

1. Bypassing user-based authorization is acceptable for API endpoints that are intentionally public or whitelisted for internal flows, provided they do not expose sensitive data or allow privilege escalation.
2. Internal endpoints might have different authentication flows compared to external API endpoints; ensure the correct middleware or whitelist status allows these internal calls to succeed.