Authorization server supports the implicit grant
The /authorize endpoint honoured response_type=token and issued an access token in the URL fragment.
What it means
OAuth 2.1 removes the implicit grant. The pattern leaks access tokens via URL fragments and browser history, has no way to bind a token to a sender and offers no refresh. The MCP authorization spec revision 2026-07-28 inherits the removal. The check sends one /authorize request with response_type=token. If the server responds with an access token in the fragment, IMPLICIT-001 fires critical. Rejecting with error=unsupported_response_type passes silently.
How to fix
Reject /authorize requests whose response_type is not code. Return a 302 redirect with error=unsupported_response_type to the registered redirect_uri. Clients that still use the implicit grant should migrate to authorization code with PKCE.
Spec
OAuth 2.1 Section 10See it live
Our demo MCP server trips IMPLICIT-001 on purpose. Scan it and you'll see this exact finding with evidence and fix text.
npx -y @patchbay-nebius/agent audit https://demo.patchbay-mcp.dev/mcp --probe-headless-oauthThe --probe-headless-oauth flag is opt-in because it sends crafted authorize requests; safe against our demo, do not point it at production servers you don't own.
Run the check against your own server:
npx -y @patchbay-nebius/agent audit <url-or-directory>No install: scan an MCP server in the browser and get a shareable report.
Disagree with this finding on your server? Open an issue with the --json output. False-positive reports are the most useful feedback.