[mangeshraut712]

Fixes #3723

/token and /revoke now use the error codes in RFC 6749 §5.2. RFC 7009 §2.2.1 reuses that presentation for revocation.

• A grant this server implements, but the client is not registered for, is unauthorized_client.
• A grant the server does not implement (client_credentials, password, or anything else outside grant_types_supported) is unsupported_grant_type, decided before the request union is validated, so the body is not a pydantic error.
• Failed client authentication on /revoke is invalid_client, the same code /token already returned.
• When that failure used Authorization: Basic, the 401 includes WWW-Authenticate: Basic realm="OAuth". RFC 7617 §2 requires the realm on a Basic challenge. client_secret_post failures do not get the header, because the client did not use the Authorization field.

The jwt-bearer path no longer has a separate "grant disabled" branch. That grant is outside grant_types_supported unless identity assertion is enabled, so the early check already returns unsupported_grant_type.

Motivation and Context

Clients that branch on these codes were reacting to the wrong condition. The two grant errors were swapped, /revoke still reported failed authentication as unauthorized_client, and a failed Basic authentication had no WWW-Authenticate header.

How Has This Been Tested?

• uv run --frozen ruff check . and uv run --frozen ruff format --check . are clean.
• uv run --frozen pyright: 0 errors, 0 warnings.
• ./scripts/test: 6223 passed, 8 skipped, 1 xfailed, coverage 100%, strict-no-cover clean.
• New cases in tests/server/auth/test_error_handling.py cover the four rows in the issue. test_client_without_the_grant_registered_is_rejected now expects unauthorized_client.

Breaking Changes

Successful token and revocation responses are unchanged. Clients or tests that matched the old error codes will see the spec codes instead: unauthorized_client rather than unsupported_grant_type when a registered client is refused a supported grant, unsupported_grant_type rather than invalid_request for client_credentials and password, and invalid_client rather than unauthorized_client when /revoke authentication fails.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I am assigned to the linked issue (or it is labeled help wanted, or I'm a maintainer)
• I have disclosed any AI assistance and can explain the change in my own words
• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Prepared with AI assistance.

Happy to adjust the realm value or the error descriptions if you'd prefer different wording.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-23T06:21:26.266359Z	68d8d68	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[github-actions]

This PR has been closed automatically. This repo only keeps pull requests open when they come from a maintainer, or from a contributor a maintainer has assigned to the linked issue, and you aren't currently assigned to #3723.

If a maintainer assigns you to #3723, this PR reopens on its own and there's nothing more you need to do here. Assignment is a maintainer call based on capacity; comments that only ask to be assigned don't factor in. What does help is engaging on the issue itself by confirming the repro, explaining why it matters for your use case, or describing the approach you'd take.

You're welcome to keep pushing commits here (just avoid force-pushing, since GitHub can't reopen a rewritten branch), but that on its own won't get the PR reviewed or the issue assigned, and realistically most auto-closed PRs stay closed. There's no need to open a new PR either way.

CONTRIBUTING.md has the full reasoning, but in short:

• We're a small team with very little capacity to review community PRs right now.
• Many recent PRs are AI-generated with little human review, and reviewing one carefully still costs a maintainer as much time as it ever did. A well-described issue is usually more useful to us than the code.

Maintainers: reopen, remove missing-issue-link, or add bypass-issue-check to override.