-
Notifications
You must be signed in to change notification settings - Fork 588
Description
Describe the bug
While exploring the MCP Registry and configuring extra_claims in docker-compose.yaml for additional OIDC token validation, I noticed an issue in how claim values are validated in the registry code.
In the following file:
registry/internal/api/handlers/v0/auth/oidc.go
The validation logic compares the actual claim value from the OIDC token with the expected value defined in docker-compose.yaml using a direct string comparison.
This works only when the claim value is a string, but breaks when the actual claim value is an array, object, or any non-string type, which is common for OIDC claims (e.g. groups, roles, aud, etc.).
To Reproduce
- Configure extra_claims in docker-compose.yaml
- MCP_REGISTRY_OIDC_EXTRA_CLAIMS=${MCP_REGISTRY_OIDC_EXTRA_CLAIMS:-[{"scp":["MCPRegisrty","admin"]}]} - The OIDC provider issues a token with the following claim payload:
{
"scp": ["MCPRegistry"]
} - Start MCP Registry
- Authenticate using OIDC
- Trigger extra_claims validation
-During authentication, MCP Registry reads:
-expectedValue = ["MCPRegisrty","admin"] (from docker-compose.yaml)
-actualValue = ["MCPRegistry"] (from the token)
- Observe the failure
- In registry/internal/api/handlers/v0/auth/oidc.go, the code compares
- actualValue and expectedValue directly as strings.
- Since actualValue is an array and not a string:
- the comparison fails
- authentication is rejected even though the token logically satisfies the requirement
Expected behavior
- extra_claims validation should:
- Gracefully handle non-string claim values such as:
- arrays (e.g. ["admin", "developer"])
- objects
- booleans / numbers
- Either:
- Perform type-aware comparisons (e.g. check membership for arrays), or
- Convert values safely before comparison, or
- Return a clear validation error instead of breaking
Logs
No logs are generated by docker
Additional context
Suggested Fix (High-level)
-->One possible approach could be:
- Inspect the type of actualValue before comparison
- Handle common cases explicitly:
[]interface{} → check if expected value exists in array
map[string]interface{} → allow key-based matching- Alternatively, normalize both values using JSON marshaling before comparison
- Or document and enforce strict typing with clearer error @messages