Skip to content

20% off your first year. Join before 2027. Claim →

OAuth checks

When MCP Tower scans a server that uses OAuth, it runs the checks below in this order. A warning or failure in a scan links to the page for that check, which will explain what was checked, what agents do when it fails, and how to fix it.

  1. Sign-in challenge: Checks that an unauthenticated request gets a 401 response whose WWW-Authenticate: Bearer header carries resource_metadata, so agents can find where to sign in.
  2. Protected resource metadata: Checks that the protected resource metadata document is found, first at the path-suffixed well-known URL and then at the root one, and that it is valid JSON.
  3. Resource identifier: Checks that the metadata’s resource equals the MCP endpoint URL, or the public hostname URL MCP Tower serves it on.
  4. Authorization servers: Checks that the metadata lists at least one authorization server in authorization_servers.
  5. Authorization server metadata: Checks that the authorization server publishes its metadata and that its issuer matches the URL the metadata was fetched for.
  6. Authorization and token endpoints: Checks that authorization_endpoint and token_endpoint are present and use https.
  7. PKCE: Checks that code_challenge_methods_supported includes S256, as the MCP authorization specification requires.
  8. Client identity: Checks how agents identify themselves: Client ID Metadata Documents with none in token_endpoint_auth_methods_supported, or Dynamic Client Registration. It warns when only Dynamic Client Registration or only manual credentials work.
  9. Client registration: Checks that Dynamic Client Registration, when it is used, succeeds and accepts MCP Tower’s redirect URI.
  10. Authorization: Checks that the authorization callback has no error, and that its iss, when present, equals the recorded issuer.
  11. Token exchange: Checks that the token endpoint returns a Bearer access token for the authorization code.
  12. Token accepted: Checks that the MCP server accepts the new token: discovery or initialize, then tools/list, succeed when authenticated.
  13. Token refresh: Checks that an expired access token can be refreshed.
  14. Tool scopes: Checks that every tool whose auth is required or optional has its declared scopes granted.
  15. Declared security schemes: Checks that every tool whose auth is required or optional declares securitySchemes, and that no tool’s top-level and _meta declarations conflict.
  16. Hidden tools: Checks that no tool appears only after signing in. Agents list tools before the user signs in.
  17. Call-time guidance: Reports what a protected tool must return when it is called without a token or without enough scope. This cannot be verified without calling the tools, so it is shown as information.
  18. Public audience: Warns when resource names the origin host instead of the public hostname. Tokens must be accepted for the hostname agents use. This warning does not fail the scan.