{"id":"atrawog-mcp-oauth-gateway","name":"mcp-oauth-gateway","homepage":"https://atrawog.github.io/mcp-oauth-gateway/","repo_url":"https://github.com/atrawog/mcp-oauth-gateway","category":"infrastructure","subcategories":[],"tags":["mcp","oauth2","authorization-server","oauth2-1","github-oauth","reverse-proxy","openid-connect-adjacent","python","reference-implementation"],"what_it_does":"mcp-oauth-gateway is an experimental OAuth 2.1 authorization layer for MCP servers. It fronts MCP endpoints with an OAuth authorization server (GitHub as IdP) and supports dynamic client registration, user login (web/device flows), token issuance (JWT/refresh), and forwarding/authentication for MCP HTTP transport, without modifying the upstream MCP server code (wrapping/bridging for HTTP transport is used).","use_cases":["Add OAuth-based user authentication and client registration to existing MCP servers","Provide a secure token-gated MCP HTTP/SSE endpoint for web/IDE clients","Enable multi-client MCP access with per-client redirect URI registration (RFC 7591/7592)","Prototype and test MCP authentication/authorization flows using GitHub login"],"not_for":["Production use without thorough security review (explicitly warned in README)","Environments requiring strict compliance assurances or certified security properties","Use cases where a simpler authentication proxy is sufficient","Workflows that cannot accommodate OAuth redirect/callback or device flow UX"],"best_when":"You want a reference/test platform to integrate OAuth 2.1 + GitHub identity with MCP endpoints while keeping upstream MCP servers unmodified.","avoid_when":"You need a turnkey, well-audited production gateway with guaranteed stability, rigorous error semantics, and published operational guarantees.","alternatives":["Directly run MCP behind your existing auth gateway (e.g., reverse proxy with OIDC)","Use a standard OAuth/OIDC reverse proxy (e.g., oauth2-proxy + your IdP) in front of MCP HTTP endpoints","Implement OAuth/OIDC at the client side (not typical for server-side MCP) and use simpler network-level protections","Build a minimal wrapper that validates JWTs and forwards to MCP (custom, but smaller surface area)"],"af_score":36.0,"security_score":64.5,"reliability_score":23.8,"package_type":"mcp_server","discovery_source":["github"],"priority":"high","status":"evaluated","version_evaluated":null,"last_evaluated":"2026-03-30T15:21:39.943872+00:00","interface":{"has_rest_api":true,"has_graphql":false,"has_grpc":false,"has_mcp_server":false,"mcp_server_url":null,"has_sdk":false,"sdk_languages":[],"openapi_spec_url":null,"webhooks":false},"auth":{"methods":["OAuth 2.1 Authorization Server endpoints","Dynamic client registration (RFC 7591/7592)","GitHub OAuth for user authentication","Device flow (RFC 8628) for non-browser scenarios (per README)","JWT bearer access tokens for MCP endpoint access","Opaque refresh tokens for token refresh","Registration access token for client management endpoints"],"oauth":true,"scopes":false,"notes":"Auth complexity is high because the gateway includes multiple OAuth flows (registration, authorize/callback, token, revoke/introspect) plus device/web flows and requires client credentials at the token endpoint; token and session state are managed via Redis."},"pricing":{"model":null,"free_tier_exists":false,"free_tier_limits":null,"paid_tiers":[],"requires_credit_card":false,"estimated_workload_costs":null,"notes":"No pricing information is provided in the supplied data (appears to be a self-hosted open-source/reference implementation)."},"requirements":{"requires_signup":false,"requires_credit_card":false,"domain_verification":false,"data_residency":[],"compliance":[],"min_contract":null},"agent_readiness":{"af_score":36.0,"security_score":64.5,"reliability_score":23.8,"mcp_server_quality":40.0,"documentation_accuracy":45.0,"error_message_quality":0.0,"error_message_notes":null,"auth_complexity":25.0,"rate_limit_clarity":10.0,"tls_enforcement":95.0,"auth_strength":80.0,"scope_granularity":45.0,"dependency_hygiene":30.0,"secret_handling":60.0,"security_notes":"README claims HTTPS everywhere, PKCE mandatory, GitHub OAuth, JWT bearer tokens, secure session management, and ALLOWED_GITHUB_USERS whitelist. It also explicitly warns the implementation is experimental and may contain bugs/vulnerabilities and is not recommended for production without security review. Dependency hygiene and concrete secret-handling/logging behavior cannot be verified from the provided text; Redis is exposed on localhost only for debugging, but operational security depends on configuration. Scope granularity is not clearly evidenced in the supplied content.","uptime_documented":0.0,"version_stability":35.0,"breaking_changes_history":30.0,"error_recovery":30.0,"idempotency_support":"false","idempotency_notes":null,"pagination_style":"none","retry_guidance_documented":false,"known_agent_gotchas":["Complex OAuth lifecycle (register → authorize → callback → token → refresh/revoke) increases agent orchestration complexity.","State management depends on Redis TTL/keys; misconfiguration may cause hard-to-debug authorization failures.","Because this is explicitly labeled experimental with possible vulnerabilities, behaviors and edge-case error formats may not be fully standardized."]}}