MCP Authentication

The Cloud Guardian MCP server uses a server-mediated OAuth flow — no secrets are embedded in the binary.

Auth Flow

  1. Call cg_login → MCP server starts a local HTTP callback server
  2. Browser opens https://cloudguard.dev/cli/auth
  3. User signs in with Google via Firebase Auth
  4. Browser POSTs the Firebase token to the localhost callback
  5. Token is stored at ~/.config/cloud-guardian/auth.json (file mode 0600)

Token Management

Tokens are automatically refreshed via securetoken.googleapis.com when they expire. The refresh token is stored alongside the ID token.

Token File Location

~/.config/cloud-guardian/auth.json

Token File Structure

{
  "id_token": "eyJ...",
  "refresh_token": "AMf...",
  "expires_at": "2026-03-08T12:00:00Z"
}

Verifying Authentication

Use cg_whoami to check your current authentication status:

> Use cg_whoami to check who I'm logged in as

Email: user@example.com
Org: My Organization (mI9dMP4nwuP5cjF5Ap6a)
Role: owner

API Keys

For CI/CD or headless environments, you can use API keys instead of browser-based auth:

  1. Create a key: cg_create_api_key with a name and role
  2. Set the environment variable: CLOUD_GUARDIAN_API_KEY=cg_...
  3. The MCP server will use the API key automatically

API keys are prefixed with cg_, stored as SHA-256 hashes, and scoped to a specific organization and role.

Security Notes

  • Tokens are stored with file mode 0600 (owner read/write only)
  • The local callback server binds to localhost only
  • No OAuth client secrets are embedded in the MCP binary
  • API key roles are capped at the creating user's role level