Use Application Passwords for your own scripts and trusted integrations; use OAuth when your app acts for other WordPress users. WordPress REST API authentication means proving who a request comes from before WordPress lets outside code read or change site data. Application Passwords give one user a separate, revokable password for API use. OAuth lets a user approve an app once, then the app uses limited tokens instead of handling that user's password.
Official resources:
- Compare WordPress REST API authentication methods — Verify when to use cookie, Application Password, or plugin-based OAuth/JWT authentication.
- Create and manage WordPress Application Passwords — Follow the official steps to generate, use, rotate, and revoke per-app credentials.
Table of Contents
- How do the two methods work?
- When do Application Passwords fit?
- When does OAuth fit?
- What are the security and upkeep trade-offs?
How do the two methods work?
Application Passwords pair a username with a long generated password. You send both with each API request, usually over HTTPS, and WordPress treats the request as that user. You can create several per user and revoke one without changing the main login.
OAuth separates the app from the user's password. The user approves access in WordPress, then the app receives tokens that authorize API calls on that user's behalf. Scopes can limit what the app may do, and tokens can expire or be revoked.
When do Application Passwords fit?
Choose Application Passwords for server-to-server work you control. Common fits are a company dashboard pulling orders, a mobile app backend owned by the site owner, or a migration script syncing posts.
Set each integration up with its own password under that user's profile. Store it like a secret, use HTTPS only, and revoke passwords when staff or services change.
- You control both the site and the client code
- Only a few trusted users need API access
- You need quick setup without an approval flow
- Calls run from a secure server, not public JavaScript
When does OAuth fit?
Choose OAuth for apps used by people who do not manage the site. Common fits are a public SaaS integration, a marketplace connector, or an agency tool installed on many client sites.
Each site owner approves access without sharing a password. Expect more setup work: register the app, handle redirects, store tokens, and refresh expired tokens. That work pays off when you support many users safely.
- Strangers or customers connect their own sites
- You need delegated access with limited permissions
- Users must grant and withdraw consent themselves
- The app runs in a browser or on many devices
What are the security and upkeep trade-offs?
Application Passwords are simple but powerful. Anyone holding the password acts fully as that user until you revoke it, so give integrations low-privilege accounts and separate passwords per service. Never place them in public JavaScript, page source, or version control.
OAuth reduces password exposure and supports narrower, time-limited access. It adds moving parts: client secrets, redirect URLs, token storage, and expiration handling. Use it when delegated consent matters, and keep token handling on your server rather than in the browser.
