OAuth authorization code is delivered to www.egnyte.com, where it can be logged

从 src/commands/auth.js 开始，包括 DEFAULT_CLIENT_SECRET 以及授权和令牌交换流程。与维护者确认 PKCE、专用回调还是环回重定向是预期的解决方案；完成的标准是授权码不会暴露给营销网站的日志记录或分析功能，并且登录流程仍能安全完成。

Summary

egnyte login uses a default redirect_uri of https://www.egnyte.com, so the OAuth authorization code is returned as a query parameter to the public marketing site. An authorization code is a credential, and delivering it in a URL to that site exposes it to logging and tracking unrelated to the login.

Where the code goes

After approval the browser lands on:

https://www.egnyte.com/?code=<authorization_code>&state=<state>

That URL, including the code, is exposed to:

• Web server and CDN access logs. Query strings are recorded by default in common server and proxy configurations.
• Client-side analytics. www.egnyte.com loads Google Tag Manager, and a standard page-view tag reports the full page location, including the query string, to the configured analytics endpoints.
• Browser history, and the Referer header on any third-party request the page makes.

Why this is exploitable, not only untidy

The CLI is a public client. Its client secret ships in the published npm package (DEFAULT_CLIENT_SECRET in src/commands/auth.js), and the authorize request does not use PKCE. The packaged secret is therefore not secret, and nothing else binds the code to the client that requested it. A code recovered from any surface above can be exchanged for a token by anyone who holds it together with the packaged secret. Single use does not close the gap: an abandoned login leaves the code unspent until it expires, and the log and analytics capture happen immediately whether or not the CLI completes the exchange.

To be precise, it is the authorization code in the query string, not the access token; the token is obtained later by a POST to /puboauth/token. The code is still a credential that yields a token.

Suggested remediation, most to least contained

1. Add PKCE (code_challenge on the authorize request, code_verifier on the token exchange). A captured code is then useless without the verifier, even if the current redirect and paste flow are kept. This also removes the need to ship a client secret.
2. If PKCE is not adopted, move the redirect off the analytics-instrumented marketing page to a dedicated callback that does not load tag managers and does not log the query string.
3. Use a loopback redirect (http://127.0.0.1:<port>) so the CLI reads the code directly and it never appears in a browser-visited URL. This also removes the manual copy-paste step.

I can open a PR for the PKCE change if that is the direction you prefer.

Related

The generated state value is not verified on return, since the CLI reads only the pasted code. That is minor on its own and would be resolved by a loopback redirect.