Stack de Auth + Identidad para MCP

What's in this pack

This is the stack for the engineer who has decided their MCP server can't ship with OPENAI_API_KEY in .env.example anymore. Every pick is open-source, production-grade, and slots into a specific layer of the auth onion. The order matters — getting the bottom layer wrong makes every layer above it lie to you.

This stack does not include 'managed Auth0 wrapper' or 'one-click SSO' SaaS. The goal is owning the trust boundary end-to-end, because if your MCP server brokers tool calls into a customer's database, the trust boundary is the product.

Install in this order

1. Infisical — secret vault, dev-facing. Replace .env files, give every service a typed secret. Self-hostable, has a CLI, has SDKs. Start here because every later tool needs somewhere to put a client secret, signing key, or webhook token. Do not skip to step 2 with secrets in plain config files.
2. sops — secret encryption for git-committed config. Infisical handles runtime; sops handles the YAML / JSON / env files you genuinely want in version control (Helm values, Terraform tfvars, GitHub Actions). Mozilla's sops is the de facto standard, uses KMS / age / PGP under the hood. Pair, don't replace.
3. OpenAuth — universal auth server you can self-host. Built by the SST team. Drop-in replacement for Auth0/Clerk if you want OAuth 2.1 + OIDC issuer of your own. Sane defaults, TypeScript-first, deploys to Lambda / Cloudflare / Node. Pick this if your MCP backend is JS/TS and you don't already have a corporate IdP.
4. OAuth Device Flow — CLI Agent Login Checklist — not a server, a checklist. CLI agents (Claude Code, Codex, Cursor, your own MCP client) authenticate via RFC 8628 device flow. This checklist covers user codes, polling intervals, token storage, refresh, and the security boundaries that bite you (verifier reuse, polling DoS, leaked codes in shell history). Read before writing the flow, not after.
5. Keycloak — heavyweight IdP for SAML / OIDC / LDAP federation. Pick this if your customers expect to wire your MCP server to Okta / Azure AD / Google Workspace via SAML. Java, batteries-included admin UI, 15+ years of CVE-fixed maturity. Heavy (1-2 GB RAM) but bulletproof.
6. Dex — lightweight OIDC identity provider with pluggable connectors. Pick this instead of Keycloak if you want a small Go binary that federates LDAP / GitHub / Google / SAML into a single OIDC issuer and stops. Kubernetes-native, no admin UI to maintain. Cloud-native shops default to Dex; enterprise shops default to Keycloak.
7. Casbin — flexible policy-based access control. After auth (who are you?) comes authz (what can you do?). Casbin gives you RBAC / ABAC / RESTful matchers in a tiny config file, with libraries in 15+ languages. Define (subject, object, action) rules and check them at every MCP tool entry point. Right-sized for app-layer scopes.
8. Open Policy Agent (OPA) — Rego-based unified policy engine for cloud-native. Pick this over Casbin when policy needs to span more than one service — admission control, sidecar enforcement, terraform plan validation, MCP gateway middleware. Heavier than Casbin, but the right answer when 'who can call this MCP tool' is the same question as 'who can deploy this pod'.
9. mcp-audit — scan MCP configs for secrets and shadow APIs. The honest audit step: point it at your MCP server config and it flags hardcoded keys, undocumented egress, and unscoped tools. Run in CI after every change. The pack you need because the other eight layers are easy to misconfigure.

How they fit together

         ┌─ Infisical (runtime secrets) ─┐
SECRETS  │                                │── used by every layer below
         └─ sops (git-tracked secrets) ──┘
             │
             ▼
AUTHN    OpenAuth  /  Keycloak  /  Dex
   (your MCP server issues / validates OIDC tokens)
             │
             ▼
FLOW     OAuth Device Flow Checklist
   (CLI agents authenticate without a browser)
             │
             ▼
AUTHZ    Casbin (in-process)  /  OPA (sidecar)
   (every MCP tool call passes through policy)
             │
             ▼
AUDIT    mcp-audit (CI gate)  +  signed audit log
   (you can prove what happened to a customer or a regulator)

The most-skipped layer is scopes — teams ship OAuth, then expose every MCP tool to every authenticated user. That's the auth equivalent of chmod 777. Pick Casbin or OPA on day one and have a policy file in the repo before the first non-toy tool ships.

Tradeoffs you'll hit

• Infisical vs HashiCorp Vault — Vault is more powerful (dynamic secrets, PKI, transit encryption, leases) but adds operational weight. Infisical wins on developer experience and is enough for 90% of MCP servers. Move to Vault when you need short-lived database credentials or your auditor asks for it.
• OpenAuth vs Keycloak vs Dex — OpenAuth = build your own IdP cheaply in TS. Keycloak = enterprise IdP with admin UI. Dex = OIDC bridge in front of an existing identity store. Don't run two of these; pick one as your token issuer.
• Casbin vs OPA — Casbin lives in-process, microsecond latency, simple model file. OPA runs as a service or sidecar, supports complex Rego, integrates with Kubernetes / Envoy / Terraform. Casbin if policy is local to your MCP server; OPA if it's organization-wide.
• Device Flow vs PKCE redirect — for CLI / agent clients with no browser, device flow is the right answer (read the checklist). For desktop or web MCP clients with a browser, PKCE redirect is simpler and safer.
• mcp-audit at gate vs at runtime — CI gate catches config drift; runtime audit catches behavior. You want both eventually; ship the CI gate first.

Common pitfalls

• Storing secrets in MCP server claude_desktop_config.json or .cursor/mcp.json — these files end up in dotfile repos, shared via screenshare, posted in issues. Reference an Infisical handle or sops-encrypted file instead of the raw value.
• Reusing the OAuth client secret across environments — MCP servers often have a dev/staging/prod split; one leaked secret then compromises three environments. Issue per-environment clients on day one.
• OIDC ID token used as bearer for tool calls — ID tokens are for the client, not for upstream APIs. Exchange for an access token with the right aud and scopes.
• Granting mcp:* scope to every authenticated user — define tool-level scopes (mcp:tool:read_file, mcp:tool:exec) and check them in middleware. Casbin / OPA exists for this exact reason.
• No audit log on tool calls — when a customer asks 'did this agent really delete that record?' you need a signed, append-only log. mcp-audit catches config issues; you still need to emit structured audit events from your MCP server itself.