Oidc Provider MCP Server
OIDC-compliant identity provider middleware for remote MCP server authorization flows.
Data last scanned today · Reviewed today
Overview
This TypeScript package functions as an Express middleware designed to simplify authorization for remote hosted MCP servers. It bridges the gap between your custom tools and existing identity providers, ensuring that your implementation adheres to the MCP Authorization Protocol without requiring deep custom integration with providers like Auth0, Clerk, or Keycloak.
Our verdict
With a security score of 48/100, this server is currently classified as high risk. A critical factor is the lack of a read-only mode, as every installation defaults to full write access. Because it is community-maintained rather than vendor-backed and has not undergone editorial review, developers should exercise caution and verify the codebase before deployment in sensitive environments.
- Supports any OIDC-compliant identity provider
- Uses only two direct dependencies
- Actively maintained with a recent commit history
- Licensed under the permissive MIT license
- No read-only mode available for safer integration
- Community-maintained without official vendor support
- High risk profile due to default full write access
Setup
{
"mcpServers": {
"mcp-oidc-provider": {
"args": [
"-y",
"mcp-oidc-provider"
],
"command": "npx"
}
}
}Paste into ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows), then restart Claude Desktop. Some servers require API keys or tokens as environment variables — check the project's README and add an "env" object if needed.
- No read-only mode — running this grants full read/write access.
Compatibility
| Client | Local | Docker | Remote | Read-only |
|---|---|---|---|---|
| Claude Desktop | ||||
| Cursor | ||||
| VS Code | ||||
| Windsurf | ||||
| ChatGPT |
Frequently asked questions
›Does this library support specific OIDC-compliant identity providers?
Yes, it is designed to work with any OIDC-compliant identity provider, including Auth0, Clerk, Okta, Keycloak, Azure AD, and Google.
›What are the requirements for deploying this in a production environment?
You must generate and persist your own JWKS (signing keys) rather than relying on the auto-generated ones used in development. This ensures that tokens remain valid after server restarts and across multiple instances in a distributed deployment.
›How should JWKS be provided in production?
You can provide your generated JWKS via the configuration options or the JWKS environment variable. If using an environment variable, ensure the key data does not contain newlines to avoid runtime configuration issues.
›Can I use this with an MCP server not built on Express?
Yes, you can run the OIDC provider as a standalone server and proxy authentication requests from your MCP server using the MCP SDK's ProxyOAuthServerProvider.
›What is required for a distributed deployment of the standalone OIDC server?
Both the standalone OIDC server and the MCP server must use a shared, persistent Keyv storage backend, such as Redis or Tigris, to ensure consistent token lookups.
Badge
Maintain this server? Add the live badge to your README.