By default, there are two basic cases for a developer to start working on a theme, or project if you like. First of all, there can be a direct customer requirement where we have to satisfy the request of a client, that is, either create a new website for them or assist them with a part of their site to solve a problem they cannot rectify on their own. Secondly, there are cases when one tries to solve a problem already existing within one’s own realm – where we know that this can come up several times in the future and this way we can save a lot of time proactively. There is a third case too, though seldom as obvious as the above mentioned examples. Here the two cases are interconnected and can help both the developer and the future clients. A prime example of this is the OAuth2, a tool that provides a solution for long-standing challenges.

What is OAuth2?

Only recently I realized that whenever a business is growing and becomes entangled in a layer of other products or websites, there is a serious need for a single sign-on solution. Due to this, I created an OAuth2 plugin for WordPress. With this plugin, I had a dual purpose. For one, I wanted to ease any future expansion of my own sites, but I also wanted to show that WordPress is capable of handling such interesting and complex tasks.

Before we dig into the technical details, in a few sentences let me outline the main concept behind OAuth2 for those, who are not familiar with this solution. In the past whenever we visited a website that required authentication, we were forced to enter our email address and a password during the process of the registration. On one hand this was a burdensome process, as the number of possible new sites a regular user visited a day was seriously growing. On the other hand I could not be fully convinced that these sites were secure enough to store my personal data. Fortunately others saw the same issue and the founding of OAuth began around this time. Here, instead of providing our data to a website, the latter contacts an authorization server that, rather than giving out our login data, acts as a mediator between the website (or in another example a printing service) and the end user. It gives the former an access token and this enables the service or website to proceed.

In other words, OAuth is a solution where:

  • The website requests authorization from the user
  • The user provides this authorization and gives consent as a proof
  • The website uses this proof in order to get a token from the authorization server (in our example this is WordPress)
  • This token is restricted to only access what the user authorized for the website.

When discussing the above, I would like to emphasize that we do not strictly speak about websites on desktops. Even a phone based application can use the certification provided by the lana.codes auth server.

How does this work for WordPress?

In order to make this solution possible in WordPress, I had to create two separate plugins. I needed an OAuth Client and an OAuth Server. From these two the latter was the one that needed a complex development. The server is obviously based on WordPress, this enables the login for other websites. Here I had to solve the requirement of handling the queries from the client side, how to generate tokens and how to establish a secure connection. Of course, the most important was for this server to use the framework of WordPress, with its users and login system.

The next and necessary part was to create the OAuth client, but this was a more adequate and easier task. Basically this is how it works:

  • Client question: “Are you logged in on the lana.codes?”
    Server answer: “Yes, here are the login entitlements, login the user with ‘admin’ access.”

In detail, this is how the OAuth server works on my site:

The OAuth server is installed on the lana.codes:

Screenshot: Lana OAuth Server – All Clients

Screenshot: Lana OAuth Server – Edit Client

On the admin page the clients (websites) need to be added, these will connect to the server with a Client ID and a Client Secret token.

The layout of the OAuth client

The OAuth client is installed on the lana.solutions/lana-editor, lana.solutions/lana-pet. While the lana-editor is the site that can be used for testing and showcasing the plugin, lana-pet supports the same for the template. As both of these are separate products, they need different subsites, due to the non-identical settings.

Screenshot: Lana OAuth Client – Settings

As it can be seen on the site, the settings are obvious. Only the URL of the OAuth server needs to be provided, but also the Client ID and the Client Secret token that was generated by the system.

This results in the below login window:

Screenshot: WordPress login – Single Sign On button

All in all, if the user is already logged in on the lana.codes, by clicking on the “Single Sign On” button the auth server in the background requests the user data from the lana.codes. This results in an automated login on the lana.solutions/lana-pet with the same entitlements.

This is how the login works:

Figure: The user is already logged in to the OAuth server website

On the contrary, if the user is not logged in on the lana.codes, they are redirected to a single sign-on website where they need to provide the login date of the lana.codes. After the successful authentication they are automatically redirected to the lana.solutions/lana-pet with the entitlements needed.

This is how the login works in this case:

Figure: The user is not logged in, so the login for the OAuth server is displayed