OAuth sign-in

OAuth sign-in lets an AI client connect to your site by approving a one-time browser prompt from your WordPress login, instead of generating and pasting an Application Password. It’s free, built in, and on by default on HTTPS sites.

Under the hood it’s a self-contained OAuth 2.1 authorization server (discovery metadata, Dynamic Client Registration, PKCE), you don’t configure any of it. The client discovers the endpoints, you click Approve, and it’s connected.

Requirements

HTTPS. OAuth is only offered on sites served over https://. On an HTTP site, use an Application Password instead.
Administrator. Only administrators can approve a connection, the consent screen refuses non-admins.
Enabled. It’s on by default when available. Confirm (or toggle) under EMCP Tools → Connection: the authentication-method chooser shows OAuth and Application password.

How it works

In your MCP client, add this site as an HTTP / Streamable-HTTP server using just the URL: no Authorization header:
```
https://your-site.com/wp-json/mcp/emcp-tools-server
```
The client detects that the server wants authorization and opens your browser.
You confirm you’re signed in as the right WordPress user and click Approve.
The client receives a token and connects. That’s it, no password ever touches the client config.

The token acts as the authorizing administrator, so every tool still runs through its own capability check, OAuth grants no extra privilege. Access tokens are short-lived (1 hour) and refresh automatically via a rotating 30-day refresh token.

Per-client steps are on each connection page: Claude Code, Claude Desktop, Cursor, VS Code, ChatGPT App, Antigravity.

Managing connected apps

Every app you approve appears under EMCP Tools → Connection → Connected apps. Click Revoke next to any app to cut its access immediately, the client will need to sign in again to reconnect.

When to use an Application Password instead

OAuth is the recommended path, but an Application Password is the right choice when:

your site is HTTP-only (OAuth is HTTPS-gated), or
your host blocks /.well-known/ requests (see below), or
you’re connecting over stdio / WP-CLI, where there’s no browser to complete the sign-in.

Application Passwords keep working alongside OAuth, nothing you’ve already set up breaks. See Auth errors if a connection fails.

Host blocking `/.well-known/`

OAuth clients discover the server by requesting /.well-known/oauth-protected-resource (RFC 9728). Some managed hosts (and some nginx/openresty defaults) deny every /.well-known/ path except ACME challenges at the web-server layer, before the request ever reaches WordPress. When that happens the client can’t discover the OAuth endpoints and sign-in fails with a discovery/404 error, even though the plugin is configured correctly.

If you hit this, either ask your host to allow /.well-known/ requests, or use an Application Password instead, it doesn’t rely on discovery.