/pom-ai-mcp/oauth/authorize: OAuth authorization
The one step in the OAuth flow that needs a human. This is where you decide which WordPress user an assistant acts as, and which scopes it gets.
https://example.com/pom-ai-mcp/oauth/authorizeYou must be logged in
If you are not logged in to WordPress, the endpoint redirects you to the login screen and returns you here afterwards.
Log in as the user whose capabilities the assistant should inherit. The authorization binds the client to that user, and their capabilities become a hard ceiling on everything the assistant can do.
Approving while logged in as an administrator gives an assistant administrator reach over content, options, theme settings and the catalogue. Consider a dedicated user holding only what the work needs.
The consent screen
The page is titled Authorize POM AI MCP access and shows:
- which client is requesting access, by its registered name;
- User — the account you are logged in as, and therefore the identity being granted;
- Resource — the MCP endpoint being authorized;
- Scopes — the list being requested;
- a reminder that the client can run tools according to this user's capabilities and the write gates an administrator enabled.
Read the User line before approving. It is the field most worth a second look, and the one people skip.
Then approve or decline. Declining returns access_denied to the client and grants nothing.
What is validated before you see it
The request is checked before the screen renders. Any of these refuses it outright:
| Check | Failure |
|---|---|
| The client is registered | invalid_client |
| The redirect URI matches the registration | invalid_redirect_uri |
| The resource matches this site's MCP endpoint | invalid_resource |
response_type is code |
unsupported_response_type |
PKCE S256 challenge is present |
invalid_pkce |
So a malformed or mismatched request never reaches the consent screen. If a client fails before showing you anything, one of these is why — and invalid_resource is the most common, meaning the client's configured URL does not exactly match the endpoint.
PKCE is required
The request must carry a code_challenge with code_challenge_method=S256. Anything else is rejected.
There is no client secret, so PKCE is what proves the client redeeming the code is the one that started the flow. See Connect with OAuth and PKCE.
Scopes
The client requests scopes; the screen shows them. Omitting the parameter falls back to what the client registered for, and unrecognised scope strings are discarded.
Approve the narrowest set that does the job. Scopes are fixed for the life of a token — widening later means repeating this flow, which is a feature rather than a nuisance. See OAuth scopes.
After you approve
An authorization code is issued and the browser is redirected to the client's registered redirect URI, carrying the code and the state value the client sent.
The code is valid for 10 minutes and can be used once. The client immediately exchanges it at the token endpoint. See The token endpoint.
Requirements
- OAuth enabled — with it off, the endpoint returns
404withoauth_disabled. - Pretty permalinks — the path is a rewrite rule and 404s without them.
The localized form /es/pom-ai-mcp/oauth/authorize is also accepted on sites where POM Translate prefixes URLs.
In the log
Successful authorizations are recorded with the client ID and the approving user. This is the entry to check when auditing who granted an assistant access, and as whom.
Revoking
There is no per-client revoke in the settings panel. Reset OAuth revokes every client, code and token for the site at once, and every connected assistant must be re-authorized.
To reduce what an already-authorized assistant can do without disconnecting it, close the relevant write gate instead. That takes effect immediately and is reversible. See Enabling writes.