Add device code authentication

[mikesellitto]

Currently, the way to authenticate the MCP server with Doppler requires hardcoding a DOPPLER_TOKEN env var somewhere. This PR adds device code authentication to create and cache CLI tokens, or cache manually entered tokens so that users don't need to declare them as env vars.

Specifically, it

• Adds a login command for browser-based device code authentication in the same vein as our CLI.
• Adds a logout command to clear those cached credentials
• Store tokens securely in system keyring
• Keeps DOPPLER_TOKEN env var support

Watch the Loom Video Here

Closes ENG-9136
Should be merged along with https://github.com/DopplerHQ/server/pull/7571

[linear]

ENG-9136 MCP server - Device Code Auth

The MCP server MVP only authenticates via Doppler tokens (personal access, service account token etc). This is fine if we're recommending scoped access as the first solution, but if we want to present the best story with the MCP release, then I think it'd be important to see if we can implement an oauth code authentication flow.

Here's what I'm proposing:

• MCP server will start without any credentials, exposing all tools by default
• Since there are no credentials, the server would start with an OAuth device code flow by presenting the user a link and code challenge
• The agent would then initiate a tool call to poll for the authentication.
• When the user authorizes with their code in Doppler, the authentication loop would close with an access token
• We'd save the access token to a user cache directory and/or the system keychain the same way that CLI does
• The initial session would continue with all tools available, present the access confirmation, and the access token acquisition tool could in theory inform the agent about which tools are usable or not (but not remove them from context at this point)
• On the next startup of the MCP server, it can acquire the cached OAuth key and start with scoped tool set if applicable

This would roughly mirror how the CLI does the code flow login, and could optionally allow users to use the tool without having to manage any local credentials.

[another-yijiao]

Tested locally in Claude Desktop with CLI flags. LGTM.

[amoses12]

Tested setting an environment variable, both methods of logging in, and logging out locally. I left one small optional comment, but this all looks great. Really nice work on this.

[amoses12]

optional/check: are we using this function anywhere? We may not need it or we may be able to utilize it in if statements where we're looking for this.config.token

[mikesellitto]

ty, this was left over from a refactor. Removed in the latest force push