Valid Authentication

generated: '2026-08-12'
method: probed
source: >-
  https://mcp.valid.co/.well-known/oauth-authorization-server and
  https://mcp.valid.co/.well-known/oauth-protected-resource (both HTTP 200,
  fetched 2026-08-12), plus observed WWW-Authenticate and error responses.
docs: null
docs_note: >-
  Valid publishes no developer authentication page. This profile is derived
  entirely from the machine-readable metadata the server itself serves and from
  live unauthenticated responses.
api: Valid Chat With Your Ads MCP Server
schemes:
- name: oauth2_authorization_code
  type: oauth2
  flow: authorizationCode
  authorization_url: https://mcp.valid.co/oauth/authorize
  token_url: https://mcp.valid.co/oauth/token
  registration_url: https://mcp.valid.co/oauth/register
  refresh_supported: true
  scopes:
    openid: OpenID Connect subject identifier
    email: Account email address
    profile: Basic profile claims
  pkce:
    required: unknown
    code_challenge_methods_supported: [S256, plain]
    note: >-
      The server advertises `plain` alongside `S256`. RFC 7636 §4.2 and the
      OAuth 2.1 draft both require S256 where the client can support it; offering
      `plain` at all is a downgrade an attacker can request. This is the single
      weakest point in an otherwise strong auth posture.
  dynamic_client_registration:
    supported: true
    endpoint: https://mcp.valid.co/oauth/register
    spec: RFC 7591
    note: GET returns 405 Method Not Allowed; registration is POST-only, as specified.
  token_endpoint_auth_methods_supported:
  - client_secret_basic
  - client_secret_post
  - none
  bearer_methods_supported: [header]
- name: outer_api_key
  type: apiKey
  in: header
  name_note: >-
    The header name is not published. An unauthenticated request to any gated path
    returns HTTP 407 {"error":"API key missing"}, which names the credential class
    but not the header. HTTP 407 is Proxy Authentication Required and the response
    carries no Proxy-Authenticate header, so this gate is non-conformant with
    RFC 9110 §15.5.8.
  applies_to: >-
    Every path on mcp.valid.co and v1.valid-gke-data-api.com EXCEPT /health and the
    three OAuth/OIDC metadata documents.
- name: mcp_bearer
  type: http
  scheme: bearer
  applies_to: https://mcp.valid.co/api/mcp/
  evidence: >-
    HTTP 401 with `www-authenticate: Bearer` and body {"detail":"Not authenticated"}
    on an anonymous JSON-RPC tools/list POST.
openid_connect:
  discovery_url: https://mcp.valid.co/.well-known/openid-configuration
  status: 200
  conformant: false
  note: >-
    The document served at the OIDC discovery path is byte-identical to the RFC 8414
    OAuth document. It omits every OIDC-required field — no `jwks_uri`, no
    `userinfo_endpoint`, no `subject_types_supported`, no
    `id_token_signing_alg_values_supported` — so despite advertising the `openid`
    scope this is an OAuth 2.0 authorization server metadata document served at an
    OIDC path, not an OpenID Provider configuration.
posture:
  summary: >-
    Strong for an unadvertised agent endpoint: OAuth 2.1-shaped authorization code
    flow with refresh tokens, PKCE, RFC 7591 dynamic client registration, RFC 8414
    authorization server metadata and RFC 9728 protected resource metadata — the
    full MCP authorization discovery chain, correctly wired. Weakened by `plain`
    PKCE remaining on offer, a non-conformant 407 outer gate, and the absence of any
    published authentication documentation.