Skip to content

extra_claims validation breaks for non-string claim values #916

@singh-priyanshi14014

Description

@singh-priyanshi14014

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

  1. Configure extra_claims in docker-compose.yaml
    - MCP_REGISTRY_OIDC_EXTRA_CLAIMS=${MCP_REGISTRY_OIDC_EXTRA_CLAIMS:-[{"scp":["MCPRegisrty","admin"]}]}
  2. The OIDC provider issues a token with the following claim payload:
    {
    "scp": ["MCPRegistry"]
    }
  3. Start MCP Registry
  4. Authenticate using OIDC
  5. Trigger extra_claims validation

-During authentication, MCP Registry reads:
-expectedValue = ["MCPRegisrty","admin"] (from docker-compose.yaml)
-actualValue = ["MCPRegistry"] (from the token)

  1. 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

  1. extra_claims validation should:
  • Gracefully handle non-string claim values such as:
  • arrays (e.g. ["admin", "developer"])
  • objects
  • booleans / numbers
  1. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions