WordPress and REST API
First and foremost, one shall understand that since version 4.4, Worpdress relies upon a REST API architecture.
This approach does not only allow developers to easily develop efficient plugins to interact with WordPress, but it also opens infinite possibilities to gain control over WordPress from a 3rd party environment, such as another application or even more from an advanced business process sequencer such as Integromat.
We’ve already touched upon API REST concept but it’s worth a quick explanation to get started.
API stands for Application Programming Interface which means that an API REST provides endpoints (URLs) and methods (GET, POST, UPDATE…) with which any piece of code can interact. To make it short, any application might connect to any WordPress site to retrieve and/or pass information on to it.
For example, should you like to gain access to the list of existing posts from this No Code wordpress instance, you could easily place the following GET
call : https://nocode.insit.net/wp-json/v2/posts
.
You would then get in return a set of information that would look like this:

But of course it won’t work and I’ll explain you why in this post.
Authentication weakness of WordPress 5
However, WordPress is currently relying upon a pretty basic authentication process which brings severe limitations to our creativity. Our goal is to find an easy workaround to access WordPress through API using a secured and efficient approach.
Problem #1: WordPress uses a cookie-related authentication method. When you log in, it updates a cookie capturing user details and let WordPress knows that you are connected to your wordpress backend.
As you see, a relevant WordPress site cannot behave in such way as you want to send API calls to WordPress even though you’re not connected to it.
Problem#2: WordPress REST API is open to anybody willing to call any existing endpoint.
In that regard, it’s up to you to decide whether you want to make your site open and accessible through API. What if the whole word would keep calling your WordPress? It could result into a major fall down!
Enabling JSON authentication
First of all, we are going to fix problem #1 by substituting WordPress standard cookie authentication for a JSON authentication approach that will enable OAuth2 scheme (JWT).
In order to achieve this, we need to download the JWT Authentication for WP REST API plugin from WordPress repository.

Don’t worry if you see a warning banner stating that the plugin has not been tested for ages. This is absolutely ok as the foundation onto which this plugin relies has remained unchanged (API REST core module of WordPress).
Once installed, it is really important to ensure that you complete a few steps in order to make sure WordPress will behave appropriately.
Configuring JWT Authentication plugin
On top of it, keep in mind that this plugin excepts a 5.3.x version of PHP installed on your server. If it not the case, please update PHP as fast as possible (which is also a good practice to keep security patches constantly updated).
Then you need to tell your web server to process Authorization headers as it seems to be disabled by default on most hosting providers. To achieve this, log into your server and find your .htaccess
file in the root of your WordPress site.
root@:/var/www/html/nocode.prod$ ll .ht*
-rwxr-xr-x 1 gru www-data 611 Jan 11 17:54 .htaccess*
root@/var/www/html/nocode.prod$
Once found, open it using your preferred text editor then add the following lines after the #END WordPress comment at the end of the file.
RewriteCond %{HTTP:Authorization} ^(.)
RewriteRule ^(.) - [E=HTTP_AUTHORIZATION:%1]

Then configure your JSON secret key which will be used to encrypt the back end forth data flow to exchange tokens and set credentials.
To do this, open your wp-config.php
file and add the 2 below lines to the top of it. Do not forget to create your own personal key that you can generate from here.
define('JWT_AUTH_SECRET_KEY', your-key-here');
define('JWT_AUTH_CORS_ENABLE', true);

Let’s test with Integromat
In your WordPress plugin section, make sure that JWT Authentication for WP-API
is effectively deactivated so that we can see what’s happening with a default WordPress API configuration.

Then you can create a basic Integromat scenario in order to understand how your WordPress will react.

When running this flow, you get a 404 error in return stating that your endpoint (URL) is not reachable which makes sense as the plugin is deactivated.

It demonstrates how this plugin is going to open a dedicated route for JSON authentication (/jwt-auth/v1/token
) to be added next to your WordPress domain. As a result, the full API call to retrieve an authentication token shall look like:
https://your.domain/wp-json/jwt-auth/v1/token
Then you just need to create a request body in the form of a JSON containing both auhtorized username and password on your WordPress site:
{
"username" : "your-admin-username",
"password" : "your-admin-password"
}
Integromat scenario to retrieve auth token
First of all, enable WT Authentication for WP-API
plugin in your WordPress.
Secondly, create the following scenario in order to retrieve a token, to make sure this token is valid then to make any kind of API call to WordPress and drive whatever behaviour you’re going after.

We have already explained how to retrieve a token. Next step consists in extracting this value from the JSON payload that we collect out from the GET TOKEN module.

In order to achieve this, we use a JSON Parsing module from Integromat. The most critical step here is to design an appropriatre data structure so that Integromat can translate the JSON payload properly and allow you to map the field you need.

Once we collect this authorization token, and for the sake of explanations, we want to check whether this token is either valid or not.
To achieve this, we are going to make a specific API call to our WordPress and gain confirmation. The endpoint we want to use is https://your.domain/wp-json/jwt-auth/v1/token/validate
and we have to use the POST method incorporating a specific header to tell WordPress that we are auhtorized to do so.

As you see, the header is following a strict formatting rule thay you cannot deviate from:
Name = "Authorization"
Value = "Bearer <space> your-token"
If you want to deep dive and get knowledge about this grammar, you might find a detailed explanation within this sharp Medium article which is worth a reading.
Then you can run your scenario to see that that your token is indeed valid. Have a look at the way Integromat built your header: each word is important as you can witness.

Then you can design any WordPress API call making sure that each time you make a request to your WordPress, you add your fresh authorization token into your API call header.
The below example shows you how to list all Users from your WordPress site without any pain, in a fully secured way.
- Endpoint =
https://your.domain/wp-json/wp/v2/users
- Method =
GET

Find hereafter the list of current WordPress endpoints that give you full control over your site.
Do not forget to add these suffixes to https://your.domain/wp-json
to make your calls valid.
Resource | Base Route |
---|---|
Posts | /wp/v2/posts |
Post Revisions | /wp/v2/posts/<id>/revisions |
Categories | /wp/v2/categories |
Tags | /wp/v2/tags |
Pages | /wp/v2/pages |
Page Revisions | /wp/v2/pages/<id>/revisions |
Comments | /wp/v2/comments |
Taxonomies | /wp/v2/taxonomies |
Media | /wp/v2/media |
Users | /wp/v2/users |
Post Types | /wp/v2/types |
Post Statuses | /wp/v2/statuses |
Settings | /wp/v2/settings |
Themes | /wp/v2/themes |
Search | /wp/v2/search |
Block Types | /wp/v2/block-types |
Blocks | /wp/v2/blocks |
Block Revisions | /wp/v2/blocks/<id>/autosaves/ |
Block Renderer | /wp/v2/block-renderer |
Block Directory Items | /wp/v2/block-directory/search |
Plugins | /wp/v2/plugins |
Disabling WordPress cookie-based authentication
We are almost done as we just need to make sure that the only way to connect to your WordPress shall go through a proper JSON Web Token authorization scheme.
To do so, download the Disable REST API
plugin from WordPress which will help shut down all endpoints, except the only ones that relate to our JSON Authentication endpoint.
To make a long story short, untick all endpoints except the 2 highligthed below that are being used each time you request a JSON token to enable the authentication process.

As of now, your WordPress is properly secured API-wise as the only way to place a call consists in asking for a valid token using the JWT scheme, then placing an API call embedding a valid token into their header (bearer token formatting).
Wrap-up
We’ve covered once again what a REST API was in order to understand all the benefits we can draw from it with the use of Integromat.
We’ve seen how WordPress was dealing with API calls by default and how weak this cookie-based scheme was.
We’ve introduced the JWT concept (JSON Web Token) which consists in calling WordPress to retrieve an authorized token so that we can place further API calls using this token.
We’ve understood how to desing authorized API calls relying on bearer token headers (in that respect, always make sure to enable SSL on your WordPress site).
Lastly, we’ve learnt how to shut down all API endpoints except the ones dedicated to JWT authentication to end up with a secure WordPress site.