Home

Welcome to Akeeba Social Login

A social login solution for Joomla!

What does it do?

This solution lets users link their social media (Facebook, Google, GitHub, Twitter, ...) account to your site. Users can then log in using their social media account on your site. A typical use case for that is Facebook login, Twitter login, GitHub login and so on.

Moreover, it allows new users to register to your site using their social media account. For example, someone can create a user account on your site using their Facebook login. This is faster for the user and easier for you, since the email address of the user has already been verified by the social network.

Finally, you can use the Social Login system to implement any kind of off-site authentication, such as integrating with a Single Sign-On solution.

Why use social login on your site.

It's easier and more secure for your users.

Users are very likely to already have an account at a social media service such as Facebook or Twitter, or have a login with an Operating System provider such as Microsoft, Apple and Google. Users are likely to be already logged into one or more of these accounts already. Using them to logging into your site, or even create an account on your site, removes a lot of friction.

Further to that, these accounts are also very likely to implement multi-factor authentication. This makes logging into them (and by extent, using the to log into your site) much more secure than the typical username and password authentication in Joomla.

First steps

We recommend reading the following pages in order:

• Requirements, Installation and Updates
• Overview of the Social Login system

Found a bug?

Please check out the existing issues. If nobody else has already reported it and you are certain it is a bug feel free to file an issue. The issue template will guide you in providing the necessary information to submit a useful issue report.

We kindly request that you do not file GitHub issues for generic support requests, off-topic questions or vague issues which require a psychic to decipher. Those issues will be closed and most likely locked without a response.

Have a suggestion?

If you have a suggestion for a feature which would benefit everyone file an issue and make your case about the feature you have in mind. Better yet, send in a PR with its implementation.

If you have a suggestion about something which would benefit only you / your organization / a very limited number of people we will probably reject it. We have very limited time so we apologize in advance if we have to turn down your project.

Before you request an integration

When we consider building an integration with a social network we try to ensure that the following basic features will be available with the resulting SocialLogin plugin (“mandatory features”):

• Logging in a user who has already linked their Joomla user account with the social network profile (linked login).
• Logging in a user who has NOT linked their Joomla user account with the social network profile yet (unlinked login).
• Create a new user account (account creation).

Moreover we consider the following optional features as a bonus (“optional features”):

• The social network explicitly or implicitly verified the user's identity and / or email address validity (identity verification).
• We can get an immutable URL to the user's avatar in a resolution of at least 128x128 pixels (avatar).

The social network requirements for the mandatory features are:

1. Returning a unique ID for each logged in user, not just a session token. This is required for linked login. If this requirement is not met we cannot implement the plugin at all (HARD BREAK).
2. Returning the user's email address. This is required for both unlinked login and account creation.
3. Returning a username, full name or other identifier that can be publicly displayed and will be used for the Joomla user's username and / or full name fields. This is required for account creation.

Account creation also requires identity verification. If it's not available we can, however, give an option to the site's administrator to allow user creation despite the lack of identity verification at their own risk. That's why we consider its availability optional.

If any of these requirements are not met we cannot develop the plugin for free since it won't be able to provide the minimum required set of features we consider essential for publicly available SocialLogin plugins.

Further reasons for rejecting the creation of an integration plugin are:

1. The service is owned by company sanctioned by the European Union or the United States of America, or is otherwise affected by such sanctions (HARD BREAK).
2. There is no public API documentation. We cannot develop an integration if we are not told how to do it (HARD BREAK).
3. The API requires libraries not readily available in PHP. In this case we can not objectively develop the integration (HARD BREAK).
4. The social network and its API documentation are not available in English. We cannot use Google Translate or anything similar when developing an integration and we can't learn a new language to develop a new plugin (HARD BREAK).
5. It's already considered and rejected in a closed issue. If we've already rejected it or removed it we won't even consider it again (HARD BREAK).
6. The API is not accessible over HTTP requests (e.g. it's only available as a JavaScript library). A JavaScript-only API has performance and privacy issues we don't want associated with the mass distributed version of SocialLogin (HARD BREAK).
7. The API requires libraries with a minimum PHP requirement higher than that of SocialLogin itself (HARD BREAK). This is self-explanatory.
8. The API is not open to the public including but not limited to requiring a fee or membership to a closed group (such as being employed by a specific company) to get API access. It should be self-explanatory: we cannot develop if we cannot get access to the API and we cannot provide integration instructions which require you to pay or otherwise be a member of a closed group to begin with. We may consider this if you accept to pay the membership, development and maintenance cost for at least 5 years.
9. The social network requirements for the mandatory features can only be met if you apply for extended API access, subject to approval based on use case. In most cases logging into a site is not an acceptable reason to get extended API access. For example, that was the reason we had removed the LinkedIn integration for a while; when LinkedIn renegged on its policy we were able to reintroduce our integration.

How to request an integration

If you are sure the integration you want to request meets the criteria outlined above please file a new GitHub issue, giving us the following information:

• Name of the social network or service the integration is about.
• A link to the API documentation. Please provide at least a link to the login flow (typically, OAuth 2 token flow) and the API used to retrieve the user's profile (email and possibly name and username / other public identifier).
• Why is this important to you and other people? Who uses this network / service?
• Are you affiliated with the network / service?

We will consider it and tell you whether we plan to develop it. We cannot give timelines / commit to deadlines; this software is developed on a best effort basis and is subject to our available time.

Please DO NOT email us directly with requests. We won't reply to you. For you it's one email. For us it's one of hundreds of emails every day and we can't keep track. GitHub is really freaking awesome at letting us track loads of requests and issues over a long period of time. That's why we use it and we want you to use it when you make requests. Thanks!

In case of rejection

If your request was rejected for any of the reasons marked as "HARD BREAK" that's the end of it. These are reasons we cannot objectively overcome. We cannot develop this plugin.

If we rejected writing the integration plugin for any other reason it's because we believe that the resulting plugin would be frustrating to you and, most importantly, your site's visitors. This does not meet our quality criteria. As a result we do not want to put out name on it.

We appreciate that you do not debate whether we can or should develop an integration we rejected for one of the listed reasons. If you disagree with our assessment you are free to develop it yourself or hire developers of your choosing to do so as long as your integration abides by the license of our software (GNU General Public License version 3, or at your option any later version published by the Free Software Foundation).

For developers

If you want to build the packages yourself please consult the Building the packages page.