OAuth provider (inbound apps)

The OAuth provider is the other direction: it lets a third-party app authenticate into your platform and call your REST surface on a user's behalf. This platform acts as the authorization server; a registered consumer is a durable configuration object you manage here.

Registering a consumer

Each consumer has:

• Grants — authorization_code (a user consents in the browser) and/or client_credentials (server-to-server, no user).
• Redirect URIs — required for the authorization-code grant.
• A bound service user — for client_credentials, the least- privilege WordPress user the issued tokens act as. There is no consent screen for this grant, so the token is deliberately scoped to a dedicated, non-admin account.
• An allowed scope and access-token TTL.

The client secret is shown once at registration and stored only as a hash — it is never retrievable afterwards.

The never-admin invariant

A token issued by the provider can never act as an administrator and its scope always intersects the bound user's real permissions — it cannot widen them. A client_credentials consumer must be bound to a non-admin service user; the platform refuses to issue otherwise. Every issued token is governed in the Tokens table.