/pom-ai-mcp/oauth/register: OAuth client registration
Dynamic client registration. A client introduces itself and receives a client ID, with no manual setup on your side.
https://example.com/pom-ai-mcp/oauth/registerPOST only. Anything else returns 405.
What the client sends
| Field | Required | Notes |
|---|---|---|
redirect_uris |
Yes | At least one; the client's callback URLs |
client_name |
No | Defaults to "MCP client"; truncated to 191 characters |
scope |
No | Omitting it registers the client for all eight scopes |
A registration with no usable redirect URI is refused with invalid_redirect_uris.
What it returns
201 with the client ID, the registered name and redirect URIs, and:
| Field | Value |
|---|---|
grant_types |
authorization_code, refresh_token |
response_types |
code |
token_endpoint_auth_method |
none |
scope |
The scopes the client may request |
No client secret is issued. Clients are public, which is why PKCE is mandatory on the authorization flow.
Registration is not authorization
This is the step people misread. Registering creates an identity for the client; it grants nothing.
The client still has to send you through the authorization endpoint, where you log in as a WordPress user and approve a specific set of scopes. A registered client with no approved authorization can do nothing at all.
So a registration appearing in the log is not a security event by itself. The authorization that follows is.
Scopes at registration
If the client omits scope, it is registered with all eight available — meaning it may request any of them later, not that it holds them. Unknown scope strings are discarded rather than rejected.
What it actually receives is decided at authorization, on the consent screen. See OAuth scopes.
Redirect URIs
The URIs registered here are the only ones the authorization endpoint will redirect to. A later authorization request naming a different URI is refused with invalid_redirect_uri.
This is what stops an authorization code being delivered somewhere you did not approve. It is enforced against the stored registration, not against anything the client asserts at authorization time.
Rate limiting
Registration is limited to 5 requests per minute per IP, sharing that budget with the token endpoint.
A client retrying a failing registration in a loop will hit it and receive 429. Wait a minute rather than retrying faster — the limit is deliberate protection against registration flooding.
Requirements
- OAuth must be enabled. With Enable OAuth off, this endpoint returns
404withoauth_disabled. - Pretty permalinks must be configured. The path is a rewrite rule; without them it returns your site's 404 page.
Multilingual sites
The localized form /es/pom-ai-mcp/oauth/register is also accepted when POM Translate prefixes URLs, while the canonical unprefixed URL stays the advertised one.
Registrations and reset
Registrations older than 30 days can expire when they have no active authorization code or token. A client that reports invalid_client must register again and complete authorization. Active grants are kept until their normal expiry or revocation.
If registration storage is temporarily unavailable, the endpoint returns an error rather than a usable client ID. Wait before retrying.
Registered clients are stored per site. Reset OAuth in the MCP settings panel removes every client, code and token for the site at once.
After a reset, a previously connected client fails with invalid_client and must register again — which a compatible client does automatically on its next connection, though you will have to approve the authorization again.
In the log
Successful registrations are recorded with the client name and the resulting client ID.
An unexpected registration in the log means something reached your registration endpoint. That is not yet a compromise — nothing is granted without an authorization you approved — but it is worth understanding, particularly if the site is publicly reachable.
Next
The authorization endpoint, where the client sends you to approve.