Allows users to login or register by authenticating with an existing Google, Facebook, LinkedIn, Github,…
New providers and features are being added regularly! See the Changelog for details.
As a reminder, WP-OAuth is a still a pre-v1.0 release, which means some features may not work as intended or might change over time. Please report any bugs/issues to the support forum so they can be fixed as soon as possible. Thank you!
Visit the GitHub development repository.
This project is a continuation of WP-OpenLogin which was originally developed with OpenID in mind. We’re moving on; OAuth 2.0 is now the standard.
Add a custom login form to your site using the [wpoa_login_form] shortcode. For example:
[wpoa_login_form layout="buttons-column" align="left"]
Possible shortcode attributes:
Not yet, see the Roadmap at our Github development repo for details.
I haven’t tried it yet, but if you do let us know! It’s on the Roadmap anyhow.
These turn your site into an OAuth2 provider which is probably not what you want. Google, Facebook and LinkedIn are providers and our goal is to be a consumer which lets us delegate user authentication to those providers.
These are similar alternatives. Some of them may include or require the use of other third-party libraries, which may add bloat or become outdated. WP-OAuth is a complete solution with zero dependencies.
With WP-OAuth, people will have the ability of logging into your WordPress site using their existing Google, Facebook or LinkedIn account. Most people probably already have one of those accounts, and they probably don’t want to register/manage yet another account. That’s where WP-OAuth bridges the gap by offering a fast and secure alternative login method which might even boost your membership and user retention. Think about it…people like to use the same passwords everywhere; they might even use their same online banking password for logging into your WordPress site. You never know, and you don’t want to be held responsible or liable for that.
Let’s say a person chooses to log into your WordPress site with Google. First they click the Google button on your site and are immediately redirected to Google’s login page. Right after logging into Google they will be prompted to grant your website permission to access some of their Google user info. Right here, you are observing OAuth in its very basic form. So once they grant access, they are redirected back to your WordPress site, along with an OAuth identity provided by Google. This identity is unique for every Google user and it never changes, so we tie the Google user’s identity to a WordPress user account. Now any time in the future when that Google user logs in with Google, we’ll match the Google user’s identity to an existing WordPress account and log them into your site automatically. If they don’t have a WordPress account, WP-OAuth can register one for them automatically as well.
 We only request the minimum amount of user info from Google (and all other providers) that will give us the user’s OAuth identity. During a request for user info, Google (and all other providers) may send additional information about the user, such as their full name or public email address. We have no way of turning that off, but it shouldn’t matter because we discard this info immediately after extracting the user’s OAuth identity. I’m not aware of any OAuth provider that lets us only ask for a user’s OAuth identity, which is kind of a let down and makes me wonder why that is.
WP-OAuth (and the official OAuth2 spec) will never get access to a user’s password from their third-party provider; instead they will be redirected to the third-party provider and then redirected back to your site with an identity. There are no exceptions, we don’t need your password and we certainly don’t want the responsibility of storing it securely! That is the wonderful nature of OAuth. When a user decides to authenticate with a third-party provider through WP-OAuth, we only ask for their basic user info – the minimum info required to obtain the user’s OAuth identity. This is not to say WP-OAuth or the OAuth2 spec is fool-proof, as nothing truly is. It turns out that each provider has decided to implement their OAuth2 API slightly differently, which leaves a lot of room for human error when it comes to developers who build and implement OAuth clients.
What makes matters worse is that developers are forced to make unavoidable assumptions as to how an OAuth client should identify users. Some implementations will identify a user by their OAuth email address, while others identify a user by their OAuth id. Technically both camps are correct – the OAuth email and id are both unique so they can be used for identifying an individual user, but we must keep in mind that even though an email is unique, it can change over time. If you ask me, a “complete” identity should consist of the OAuth email AND id. Without the email, we have no method of reverse lookup, no way to contact the user if they need to recover their account. And without the id, we could lose track of the user when he/she changes their email address.
OAuth2 doesn’t abide by strict standards, and that is what I believe to be the most troubling aspect of it, which the ex-lead developer of OAuth2 has spoken openly about. With all that said, OAuth2 is still viable and will remain prevalent in the web landscape for years to come. I think we just need stronger and stricter specifications so it is easier to implement correctly for both providers and clients. With WP-OAuth, we’ve taken the time to understand these gory details in the attempt to deliver a solid plugin and clean code base.
For more information, see:
OpenID functions on the assumption that each person will have their own unique identity that can be validated by a third party. However, most people don’t have an OpenID and probably don’t care for one, which makes OAuth a better choice for non-enterprise login systems because most people do have a Google, Facebook or LinkedIn account and should already be familiar with the authentication process of those providers. OpenID Connect is just OAuth 2.0 tailored for user authentication, and WP-OAuth aims to support providers that use either one.
The latter two technologies are for enterprise-scale apps and environments where a single identity is used to gain access to any site or app within an enterprise environment, whether locally or remotely. Basically, the user signs in once and for the lifetime of their session they will have secure, authenticated access to all resources in the enterprise environment. This is not exactly what OAuth2 was designed for. OAuth2 lets us request information about a user from a trusted third-party, which we can assume to be authentic, allowing us to identify the user in some way and associate that user identity with a user account in our site or app. The main difference is that with OAuth2, each site or app that is requesting your user information must be explicitly granted permission by you in order to access it. This access can also be revoked by you. This gives users full control over their personal info and what sites or apps may use it. OAuth2 was designed with REST in mind and functions exclusively over the HTTP protocol, whereas SAML allows for other implementations.