terraphim / terraphim/terraphim-ai
feat: Implement MCP authentication and security enhancements
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 62
- Forks
- 5
- Avg merge
- 2h 27m
- Merged PRs (30d)
- 1
Description
Summary
Implement comprehensive MCP authentication system based on closed PR #287.
Design Plan
See .docs/plans/mcp-authentication-design.md for full design document.
Key Features
- Authentication Middleware: Bearer token validation with SHA256 hashing
- Three-Layer Security: exists + enabled + expiration validation
- Rate Limiting: Configurable request limits with sliding window
- Security Logging: Comprehensive audit trail for attack detection
Implementation Phases
| Phase | Duration | Deliverable |
|---|---|---|
| Phase 1: Foundation | 2 days | Auth module structure, token validator |
| Phase 2: Middleware | 2 days | Working auth on SSE routes |
| Phase 3: Rate Limiting | 1 day | Sliding window implementation |
| Phase 4: Hardening | 2 days | Logging, tests, documentation |
Acceptance Criteria
- Request without Authorization header returns 401
- Request with invalid/expired token returns 401
- Request exceeding rate limit returns 429
- Valid token allows tool invocation
- Security events logged with timestamp, IP, token_id
- Stdio transport works without token (backward compatible)
Origin
Based on closed PR #287 which had conflicts with current codebase. Fresh implementation approach.
Labels
security, enhancement, mcp
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with .docs/plans/mcp-authentication-design.md and compare the closed PR #287 with the current codebase, focusing on the SSE routes and stdio transport. Trace where authentication middleware and token handling belong before implementing the planned phases. Done means the listed 401, 429, logging, valid-token, and backward-compatible stdio acceptance criteria pass.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- api, backend, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100