WordPress REST API authentication: application passwords vs JWT vs OAuth
TL;DR: Application Passwords, built into WordPress core since version 5.6, provide a straightforward, no-plugin-required way for a trusted application to authenticate against your REST API using a dedicated, revocable credential separate from your actual account password, sufficient for the large majority of simple integration needs. JWT (JSON Web Tokens) adds stateless, token-based authentication useful specifically for scenarios needing token expiration control and cross-service authentication without repeated credential transmission. OAuth is the most complex of the three, specifically designed for scenarios where a third-party application needs delegated access to a user's WordPress account without ever directly handling that user's actual credentials, relevant mainly for public, multi-user integration scenarios most single-business WordPress sites do not actually have.
Why authentication method choice matters for the REST API specifically
WordPress's REST API, covered in the context of a common access issue in our dedicated REST API 403 guide, allows external applications to interact with your site programmatically, and any request performing an action beyond basic public, unauthenticated reads needs some mechanism to prove it is authorized to act on behalf of a specific user or application. The three approaches covered here solve this authentication problem with genuinely different trade-offs in complexity, security model, and appropriate use case, and choosing the wrong one for your specific situation means either unnecessary implementation complexity or, in the other direction, insufficient security control for what you are actually trying to achieve.
Application Passwords
Introduced as a core WordPress feature (no plugin required) in version 5.6, Application Passwords let a user generate a dedicated, randomly-generated credential specifically for a given application's use, entirely separate from and independent of their actual account login password, meaning the application authenticates using this dedicated credential rather than ever needing the user's real password. Each generated application password can be individually named (helping track which application it belongs to) and individually revoked without affecting the user's actual account password or any other application's separately generated credential, providing reasonable, granular control with minimal setup complexity, directly built into WordPress core with no additional plugin dependency.
JWT (JSON Web Tokens)
JWT-based authentication, implemented via a dedicated plugin since it is not built into WordPress core, issues a signed, typically time-limited token after an initial authentication step, with subsequent requests including this token rather than repeatedly transmitting the underlying credentials. This is particularly useful for scenarios involving a genuinely stateless, scalable authentication pattern (common in modern single-page applications or mobile apps making frequent API calls) where you specifically want tokens to expire automatically after a defined period, requiring re-authentication, rather than a credential remaining valid indefinitely until manually revoked the way an Application Password does by default.
OAuth
OAuth is specifically designed for delegated authorization, allowing a third-party application to gain limited, scoped access to a user's account without that user ever directly sharing their actual credentials with the third-party application at all, instead authorizing access through a dedicated authorization flow (the familiar "log in with X" pattern many web services use) that grants the third-party application a token representing specifically the permissions the user explicitly authorized. This is considerably more complex to implement than either of the other two methods, and is specifically warranted when you are building a genuinely public-facing integration or plugin meant to be used by many different WordPress site owners' own users, each independently authorizing access, rather than a private, internal integration for your own single site that you directly control and configure yourself.
A comparison table
| Factor | Application Passwords | JWT | OAuth |
|---|---|---|---|
| Built into WordPress core | Yes | No, requires a plugin | No, requires a plugin |
| Implementation complexity | Low | Moderate | High |
| Token/credential expiration control | Manual revocation only, no automatic expiration | Built-in, configurable expiration | Built-in, configurable expiration and scoping |
| Best suited for | Simple, private integrations you directly control | Stateless apps needing automatic token expiration | Public, multi-user third-party integrations |
| Requires the user to ever share their real password | No | Depends on initial auth step | No, by design |
Which one for which use case
For the large majority of typical WordPress integration needs, a custom script pulling data into an internal dashboard, a mobile app you built and control accessing your own site's content, a simple automation connecting WordPress to another internal tool, Application Passwords provide sufficient security and control with the least implementation complexity, and being built into core means no additional plugin dependency or maintenance overhead. JWT becomes worth the added complexity specifically when you need genuine, automatic token expiration as a security control (rather than relying purely on manual revocation) or are building a more genuinely stateless, scalable client application architecture. OAuth is specifically warranted when building a genuine, public-facing third-party integration or plugin meant for other WordPress site owners' own users to independently authorize, a considerably narrower, more specific use case than most single-business WordPress API integration needs actually represent.
Security considerations across all three
Regardless of which method you choose, a few practices apply broadly: always use HTTPS (covered across our SSL-related guides) for any API authentication, since transmitting credentials or tokens over an unencrypted connection defeats the security purpose of any of these methods entirely. Apply the principle of least privilege, granting only the specific access an integration genuinely needs rather than broad, unrestricted access by default. And apply rate limiting to your API endpoints, covered in our dedicated rate limiting guide, regardless of which authentication method is used, since authentication controls who can access an endpoint, not how much they can do once authenticated, a separate, complementary protection layer.
FAQs
Can I use Application Passwords without installing any additional plugin?
Yes, this is specifically the appeal of Application Passwords, since the feature has been built directly into WordPress core since version 5.6, requiring no additional plugin at all, unlike JWT and OAuth which both require a dedicated plugin to implement.
Does an Application Password expire automatically?
No, by default an Application Password remains valid indefinitely until manually revoked by the user who created it, a meaningful difference from JWT's typical automatic expiration behavior, worth considering if automatic, time-based credential expiration is a specific security requirement for your particular use case.
Is JWT more secure than Application Passwords?
Not inherently more secure in an absolute sense, since both can be implemented securely or insecurely depending on configuration; JWT's specific advantage is automatic token expiration and a more stateless architecture pattern, not a fundamentally stronger security model than a properly managed Application Password for a comparable, appropriately-scoped use case.
Do I need OAuth if I'm just building an integration for my own single WordPress site?
Generally no, OAuth's specific value, delegated authorization without sharing credentials, matters most when many different, independent users need to individually authorize access to their own separate accounts; for your own single site that you directly control, Application Passwords or JWT are typically sufficient without OAuth's additional complexity.
Can I revoke access if an Application Password is ever compromised?
Yes, revoking a specific Application Password is straightforward through the WordPress user profile interface, immediately invalidating that specific credential without affecting the user's actual account password or any other separately generated application password.
Does using any of these three methods protect against a brute-force attack on the API itself?
Not directly on its own; authentication method choice determines how legitimate access is granted and verified, while protecting against brute-force attempts against the authentication endpoint itself requires separate measures like rate limiting, covered in our dedicated guide, a complementary rather than substitute protection.
Is there a scenario where I'd want to use more than one of these methods on the same site?
Yes, a site might reasonably use Application Passwords for a few simple, internal integrations while also supporting OAuth for a genuinely public-facing plugin or service meant for broader, independent third-party use, since these serve genuinely different use cases that can coexist without conflict on the same underlying WordPress installation.
Conclusion
Application Passwords, built into WordPress core, provide sufficient, appropriately-scoped authentication for the large majority of typical, private WordPress API integration needs with minimal implementation complexity. JWT is worth the added complexity specifically when genuine, automatic token expiration is a requirement, and OAuth is specifically warranted for genuine, public-facing, multi-user third-party integrations, a considerably narrower use case than most single-business integration needs actually represent.
Choosing the simplest method that genuinely meets your specific security and architectural requirements, rather than defaulting to the most complex option out of an assumption that more complexity automatically means more security, is the more practical approach for most WordPress integration projects.
HostCloud's hosting supports all three authentication approaches without any specific configuration limitations, and our team can advise on which method genuinely fits your specific integration's actual requirements. See plans at https://hostcloud.in.