René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"support GitHub App installation‑token authentication (server‑to‑server) for MCP","articleBody":"### Describe the feature or problem you’d like to solve\n\nMCP can currently authenticate with:\n\n* Personal Access Tokens (classic or fine‑grained) ✨\n* *Soon 🚀*: OAuth 2.0 device‑code flow via https://github.com/github/github-mcp-server/issues/132\n\nBoth approaches depend on credentials that are bound to a *human* account.  \nIn enterprises(including ours) PAT creation is **often blocked**, and a device‑code token still requires a privileged “service user” to stay alive.  \nThat leaves 24 × 7, org‑wide automation brittle and out of step with GitHub’s own security guidance.\n\n| Concern | Fine‑grained  PAT | OAuth device‑code |\n|---------|-----------------|-------------------|\n| 👤 Identity coupling | Single user  →  breaks on off‑boarding | Needs service user |\n| ⏳ Secret lifetime | Up to 1 year; manual/scripted rotation | 8 h access token + 6 mo refresh token |\n| 🔍 Audit clarity | Traffic appears as that user | `oauth-app/\u003capp\u003e (as @user)` |\n| 🛡️ Org policies | PATs often disallowed | Refresh token is still long‑lived |\n\nSo, neither option is ideal for a headless, fleet‑wide MCP deployment.\n\n*Visual cheat‑sheet (PAT vs device‑code vs GitHub App installation):*  \n\u003cimg width=\"1091\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/fb2761b6-f829-433d-817b-ae1dc9e0a815\" /\u003e\n\n\n### Proposed solution\n\nAllow **GitHub App installation‑token (server‑to‑server) authentication**.\n\n* install the App at org/enterprise scope with the minimum perms MCP needs (`contents:read`, `metadata:read`, etc)  \n* store only the App’s private key in AWS Secrets Manager / KMS\n* at runtime MCP signs a short‑lived JWT → exchanges it for a 60‑minute installation token → refreshes automatically\n* audit events appear as `github‑app/mcp‑server`\n\n**Benefits**\n\n* **zero human coupling** – no PATs, survives re‑orgs and off‑boarding\n* **short‑lived creds** – ≤ 60 min window if a token leaks\n* **governance** – admins can see/change App permissions \u0026 repo list in one click\n* **clear audit trail** – bot traffic is obvious (`github‑app/…`)\n* **future‑proof** – aligns MCP with GitHub’s move away from long‑lived personal tokens\n\n### Additional context\n\n**Suggested implementation approach**\n\n1. add `--auth=github-app` flag\n2. read `APP_ID`, `INSTALLATION_ID`, private‑key path/env var\n3. generate JWT (RS256) → `POST /app/installations/{id}/access_tokens`\n4. inject token into existing GitHub client; transparently refresh on HTTP 401/expiry\n\n*Architecture sketch of MCP + GitHub App flow:*  \n\u003cimg width=\"572\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/80bc9a9a-48d8-4ff8-9141-59b5d429f564\" /\u003e\n\nHappy to help spec out more, test, etc - just let me know what’s useful 🙌\n","author":{"url":"https://github.com/Svetlanko","@type":"Person","name":"Svetlanko"},"datePublished":"2025-04-18T21:47:14.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":6},"url":"https://github.com/311/github-mcp-server/issues/311"}