WordPress REST API Authentication Methods Compared

The WordPress REST API supports several authentication methods, and choosing the wrong one leads to either security vulnerabilities or unnecessary complexity.

Cookie Authentication (Default)

When a user is logged into WordPress, the REST API automatically authenticates them via their session cookie. This is perfect for admin-facing features and Gutenberg blocks — no extra setup needed. But it only works for same-origin requests from the WordPress admin.

Application Passwords

Built into WordPress core since 5.6, Application Passwords are the simplest method for external integrations:

# Generate via WP-CLI
wp user application-password create admin "My App" --porcelain

# Use with HTTP Basic Auth
curl -u admin:xxxx-xxxx-xxxx-xxxx https://example.com/wp-json/wp/v2/posts

Each application gets its own password that can be revoked independently. Good for server-to-server communication, CI/CD pipelines, and mobile apps.

JWT (JSON Web Tokens)

For headless frontends where users authenticate through your custom UI, JWT makes sense. The user logs in once, gets a token, and includes it in subsequent requests. The token expires, so stolen tokens have limited impact.

When to Use What

• Same-origin WordPress admin: Cookie auth (automatic)
• Server-to-server or scripts: Application Passwords
• Headless frontend with user login: JWT
• Public read-only endpoints: No auth needed

For most WordPress projects, Application Passwords cover 90% of external authentication needs. Only reach for JWT if you are building a full headless application with client-side user authentication.