More and more websites offer their users the ability to register and log in using credentials from third parties such as Amazon, Facebook, Google or LinkedIn as opposed to creating a unique username and password for said website.

The obvious advantage for the user is that they have to remember less passwords, but is that safe or is that user potentially allowing that third-party unlimited access to the information of the website?

That question was raised during a recent conversation with a customer and I would like to address it here.

To start, let’s analyze how third-party authentication works based on the following scenario:

A user, Alice, wants access to the AmazingApp website. The AmazingApp (AA) website developers have added a nice feature so that Alice can register and log on (‘IN’ IPV ‘ON’?) using her SocialWonder (SW) account info. She clicks on the SW link and is redirected to the SW login page. When her credentials are validated, the SW website redirects her back to the AA website with a unique session code. At this point Alice is authenticated but not yet identified in the AA system. Assuming the email address is used to identify the user in the AA system, which is usually the case, the AA application now requests the users email address from SW using the provided session code together with a secret code that was generated when the AA developers registered their app with SW. The secret code is to ensure that it is really the AA application that is requesting that data and not some other entity that has somehow intercepted the session code.

With the email address, the AmazingApp can identify the user and provide access to the website based on the user’s role and permissions.

If the returned email address doesn’t exist in the AA database yet, Alice is registered as new user identified by the email address.

Alternatively, the AmazingApp can register the user based on their socialMedia ID. However, the format of such an ID is not standardized so this is less likely to being used if multiple providers can be used to authenticate a user. For example: a Linkedin userId looks like ‘H0i-5zIMye’ whereas a Facebook useId looks like ‘9495390900803521’. On both sites an email address looks the same, so that is the easiest common denominator to use by the AA site.

The diagram below shows the interactions when loggin in using a third party authentication service.

So now back to the question: Is it safe, or am I giving SocialWonder potentially full access to my AmazingApp account. From the above it is obvious that the answer is yes, you are potentially giving SW full access.

SocialWonder initiates a login from AA website. It then returns a session code, any session code. Note that SW doesn’t need to know the user’s PW at this point. It just generates a session code. The AA app then uses that session code to obtain the email address and identify the user. SW return the email address for the account it wants access to and BINGO!

Is that a likely scenario though? Not really. Sooner rather than later someone will discover what SW is doing and SocialWonder’s credibility is shattered overnight.

So is third-party authentication a good idea? In most cases it is. The user needs to keep in mind, though that all the websites where they use their third-party credentials are vulnerable if their third party account is compromised. As long as a user is diligent about securing their main accounts used for third party authentication, the benefit of having to maintain a plethora of usernames and passwords can greatly benefit efficiency and convenience.

In order to use a 3rd party for user authentication the developer of the website or application needs to register that application with the 3rd party. Upon registration the developer receives a Client ID, or app code which is used to identify the application when a user logs in, and an application secret with is used to authenticate the application. This secret should never be shared and a new secret should be requested when abuse is suspected.