/.well-known/oauth-authorization-server: authorization-server discovery

The second discovery document. It tells a client where the OAuth endpoints are and what this authorization server supports.

https://example.com/.well-known/oauth-authorization-server

GET, public, returns JSON.

What it contains

Reading the constraints

Four of these fields are the whole security posture of the flow, stated up front:

response_types_supported: code. Only the authorization code flow. Implicit and other flows are not offered.

code_challenge_methods_supported: S256. PKCE is mandatory and only the SHA-256 method is accepted. A client sending plain, or no challenge at all, is refused with invalid_pkce.

token_endpoint_auth_methods_supported: none. There is no client secret. Clients are public, which is correct for locally running assistants — and precisely why PKCE is not optional.

grant_types_supported. Authorization code to obtain tokens, refresh token to renew them. Nothing else.

The scopes

scopes_supported lists the scopes this server understands. Direct site connections advertise eight site scopes; the account gateway advertises its own account scopes. A client uses this to know what it may request; it does not imply any of them will be granted.

Approval happens on the consent screen, and scopes are only one of the four checks a call must pass. See OAuth scopes.

The issuer

The issuer is the site's own root URL, and it matches the entry in authorization_servers in the protected resource metadata. Clients verify the two agree before trusting the document.

Each site is its own issuer. On multisite, every site advertises a different issuer and issues tokens that work only there.

It is a rewrite rule

Like the protected resource document, this path is served through a WordPress rewrite rule.

• Pretty permalinks are required, or it returns your 404 page.
• A real .well-known directory on disk can shadow it, in which case WordPress never sees the request.

If the protected resource document works and this one does not, suspect a physical file at this specific path.

Multilingual sites

The localized form — /es/.well-known/oauth-authorization-server — is also answered when POM Translate prefixes URLs, while the canonical unprefixed URL remains the advertised one.

Caching and CORS

Sent with no-store cache headers and a JSON content type. Cross-origin requests are answered only for allowlisted origins, with OPTIONS returning 204.

A cached copy after a domain change points clients at endpoints that no longer match the resource, producing invalid_resource at the token step. Exclude the path from CDN caching.

Checking it

Open it in a browser and confirm the endpoint URLs use your canonical host and the same scheme as the MCP endpoint. A mismatch between what this document advertises and what the client was configured with is the root of most invalid_resource failures.

The diagnostics in the MCP settings panel fetch it from the server and report status, content type and whether it parsed as JSON.

Revoke an individual grant

Send POST to the advertised revocation_endpoint with the credential in token and its registered client_id. Both JSON and form encoding are accepted. The matching access and refresh credentials are revoked together. Unknown or already revoked credentials receive the same HTTP 200 response, without revealing whether a grant exists. No WordPress cookie nonce or client secret is used for this token-based protocol operation. Other clients remain authorized. Keep credentials in the client’s protected connection settings.

Next

• The registration endpoint
• The authorization endpoint
• The token endpoint