Skip to main content
ezForge uses two separate auth systems:
  1. Platform auth — authenticates you (the developer) to the ezForge API and CLI
  2. MCP auth — authenticates MCP clients (AI assistants) to your deployed servers

​
Platform authentication

​
API keys

API keys are scoped, revocable credentials for programmatic access to the ezForge control plane. Create an API key in the dashboard under Project → API Keys, or via the CLI: 
ezforge project create-key my-first-project --name "ci-deploy" --scopes "deployments:write,servers:read"
Keys use the prefix ezf_live_ (production) or ezf_test_ (test environment). Available scopes:
ScopeDescription
servers:readList and view servers
servers:writeCreate, update, delete servers
deployments:readView deployment history
deployments:writeTrigger deploys and rollbacks
logs:readStream server logs
metrics:readView server metrics
billing:readView billing and usage
Using an API key: 
curl -H "Authorization: Bearer ezf_live_..." https://api.ezforge.ai/v1/projects

​
Session tokens

The ezForge CLI and dashboard use session-based auth (HTTP-only cookies, 1-hour expiry). Use ezforge auth login to authenticate the CLI.

​
MCP authentication

Every deployed MCP server is protected by OAuth 2.1 with mandatory PKCE (S256 code challenge method). This means MCP clients must complete an authorization flow before they can call your server’s tools.

​
ezforge_managed mode (default)

ezForge acts as the OAuth authorization server. No configuration needed — your server is protected out of the box. Client registration — two paths:
PathWhen to use
CIMD (preferred)Your client can host a metadata document at a stable HTTPS URL
DCR (fallback)Your client cannot host a metadata document
CIMD (Client ID Metadata Document) — the MCP spec’s preferred path. Your client uses its own metadata URL as client_id. ezForge auto-fetches and registers the client on first authorization request. No separate registration call required. DCR (Dynamic Client Registration, RFC 7591) — POST metadata to /api/v1/servers/:id/clients or include clientMetadataUrl in the body for CIMD explicit pre-registration. MCP clients discover auth metadata via the standard .well-known endpoints: 
GET https://auth.ezforge.ai/.well-known/oauth-authorization-server
This returns RFC 8414 Authorization Server Metadata, including "client_registration_types_supported": ["automatic"], signalling CIMD support. MCP clients also discover protected resource metadata via: 
GET https://{slug}.mcp.ezforge.ai/.well-known/oauth-protected-resource
Response: 
{
  "resource": "https://my-server.mcp.ezforge.ai",
  "authorization_servers": ["https://auth.ezforge.ai"],
  "scopes_supported": ["mcp:read", "mcp:write", "mcp:execute", "offline_access"],
  "bearer_methods_supported": ["header"]
}

​
BYOA mode (Bring Your Own Auth)

If you have an existing OAuth 2.1 authorization server, you can configure your server to accept tokens from it: 
ezforge servers update my-server \
  --auth-mode byoa \
  --byoa-issuer https://auth.example.com \
  --byoa-jwks-uri https://auth.example.com/.well-known/jwks.json \
  --byoa-authorization-endpoint https://auth.example.com/oauth/authorize \
  --byoa-token-endpoint https://auth.example.com/oauth/token
ezForge validates incoming tokens against your JWKS endpoint, bound to the specific server URI (RFC 8707 Resource Indicators).

​
OAuth scopes

ScopeDescription
mcp:readList available tools
mcp:writeCall tools that modify state
mcp:executeExecute arbitrary tool calls
offline_accessRequest refresh tokens

​
Token lifetimes

Token typeLifetime
Access token15 minutes
Refresh token30 days (rotated on use)
Auth code10 minutes (single-use)