Erik Peña
Uncategorized

Enabling OAuth 1.0a for WordPress

This article covers setting up an OAuth server within WordPress that complies with the OAuth 1.0a standard.  This is done to allow authorized API access against your installation of WordPress.

Installing the OAuth Server

First things first, you will need to acquire the OAuth server WordPress plugin.  The link to this is https://wordpress.org/plugins/rest-api-oauth1/ (Or, on github — https://github.com/WP-API/OAuth1).  This plugin supports OAuth’s 3-legged authorization flow.

After you have installed and enabled the plugin, you can go to the “Users” > “Applications” menu item in your WordPress installation.  Here, you will add a new Application Title, Description and Callback Url.  The Callback Url is pre-determined url that WordPress will redirect the user to after the user has successfully authorized access to the application.  Be sure to use a valid Callback Url as the OAuth server will verify that the callback urls match.

After saving the Application configuration, you will be presented the OAuth configuration for the application which includes the  Client Key (also referred to as the Consumer Key) and Client Secret (also referred to as Consumer Secret).

Tip — If you’re developing your application and testing it against your OAuth server, you can modify your system’s hosts file to have the domain you specify to resolve to your localhost.  Make sure to reset your hosts file when you are done.

Recommendation — In a real-world case, you will never have your Client Secret value implemented on any client code.  Brokering OAuth calls are generally done through a web service layer that abstracts logic and that securely holds any secrets.

One last thing, once you have successfully tested authenticating your application (covered in the next section), you’ll be able to verify a your access to an application by going to the “Users” > “Your Profile” WordPress menu item and scrolling down to the “Authorized applications” section to see your applications with an option to Revoke access (if desired).

Verifying OAuth

To verify the OAuth server, I am choosing to demonstrate how 3-legged flow works using POSTman as opposed to any specific client library implementation.  The reason for this is that I want to educate the reader with a deeper understanding of the authentication flow so that they are armed with with this knowledge which helps when troubleshooting a client integration.

The 3-legged authorization flow involves three (3) steps to be considered successful (not more or less).  Here is a primer of the purpose each of these steps–

request – The first step is a call against your WordPress installation to retrieve some temporary keys that your application will use in the authorization request.

authorize – The authorization step is a visual process that requires the user to manually accept (authorize) the application using their user permissions.  The result of this is a verifier key value that gets used in the last step.

access – Using the temporary keys and the verifier key values, a request is made to generate and acquire a set of keys that are used for the API calls.

To figure out what the OAuth Urls are for your WordPress installation, you can make a request against your root with a “/wp-json” appended to the url.  For example, if the root to your WordPress server was “https://www.somecoolblog.com”, you can expect this url to be “https://www.somecoolblog.com/wp-json”.

Making a request to this Url will return a huge Json response.  In this response, you can do a search for “oauth” to find the urls you’ll need.  Below is an example of what to expect (truncated for brevity)–

{
    ...
    "authentication":{
        "oauth1":{
            "request":"https:\/\/www.somecoolblog.com\/oauth1\/request",
            "authorize":"https:\/\/www.somecoolblog.com\/oauth1\/authorize",
            "access":"https:\/\/www.somecoolblog.com\/oauth1\/access",
            "version":"0.1"
        }
    },
    ...
}

With the Client Key (Consumer Key), Client Secret (Consumer Secret) and the Urls above, we can now make the calls to verify the OAuth configuration.

Request Call

To make the request call in POSTman, define the “request” url in the Url field, set the method to “POST”, and open the Authorization tab.  In the Authorization tab, select the “OAuth 1.0” Type value.  In the fields that are displayed, define the Consumer Key (Client Key) and Consumer Secret (Client Secret).  Set the Signature Method field to “HMAC-SHA1” (This is the preferred signature method by the WordPress plugin).  Lastly, set the Version field to “1.0”.

On the right hand side of the fields, you’ll notice a set of checkboxes are available.  Check the “Add params to header”.  This option will take the OAuth parameters that are generated and will create an Authorization HTTP request header (as opposed to a form POST body).

Click the “Update Request” button to generate a value for the Nonce and Timestamp fields.  The request context in POSTman is also updated with all the information in the Authorization tab as well.  POSTman should look like similar to the following–

Click the “Send” button to initiate the call.  Upon response, you’ll get a body that contains the temporary token and secret values.  These will be used in the authorize or access calls.  Here is an example of what the response should look like–

Authorization Call

The authorize call is part programmatic/part manual in that your application will need to generate a Url that your user will need to be automatically redirected to.  Once the user has been taken to this Url, they need to manually click a button that authorizes access for your application to make calls against WordPress.

To generate the authorize Url, take the url defined by WordPress and apply an “oauth_token” query parameter and set the value of this query parameter to the “oauth_token” response value from the request call.  This generated authorize Url should look similar to the following–

https://www.somecoolblog.com/oauth1/authorize?oauth_token=2FFojkUQbpLJmhcev40qP3R6

In your browser of choice, request this authorize Url.  This simulates what the application will do by redirecting the user to the authorize Url programmatically.  When the authorize Url is loaded, a webpage generated by WordPress is presented with an option to Authorize or Cancel the authorization of access to the application–

Clicking the Authorize button will redirect the user to another WordPress hosted page.  This page contains a verification token value that is used in the access call.

Note — For the sake of POSTman, we’re not taking advantage of OAuth’s ability to redirect the user back to your application by the use of the “oauth_callback” query parameter.

Access Call

The last stage to this process is the access call which trades the temporary keys that were retrieved from the request call for a set of “more” permanent status.

To make the access call in POSTman, define the “access” Url in the Url field, set the method to “GET”.  Append a “oauth_verifier” query parameter to the access Url and set the value to the verification token that was retrieved in the authorize call.

open the Authorization tab.  In the Authorization tab, select the “OAuth 1.0” Type value.  In the fields that are displayed, define the Consumer Key (Client Key) and Consumer Secret (Client Secret).  Also, set the temporary “oauth_token” in the Token field and the “oauth_token_secret” in the Token Secret field.  Set the Signature Method field to “HMAC-SHA1”.  Lastly, set the Version field to “1.0”.

On the right hand side of the fields, you’ll notice a set of checkboxes are available.  Check the “Add params to header”.  Click the “Update Request” button to generate a value for the Nonce and Timestamp fields.  The request context in POSTman is also updated with all the information in the Authorization tab as well.  POSTman should look like similar to the following–

Click the “Send” button to initiate the call.  Upon response, you’ll get a body that contains the new token and secret values that can be used in API calls against WordPress–

That’s it!  You just manually walked through the 3-legged authorization flow of OAuth 1.0a.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.