Is third-party authentication a good idea?
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 instead of creating a unique username and password for the website.
The obvious advantage for the user is that they have fewer passwords to remember. But is it safe, or does this potentially allow the third party unlimited access to the information on the website?
This question was raised during a recent conversation with a customer, and I would like to address it here.
How Third-Party Authentication Works
To understand the process, let’s analyze a typical scenario:
A user, Alice, wants to access the AmazingApp website. The AmazingApp (AA) developers have implemented a feature that allows Alice to register and log in using her SocialWonder (SW) account information. When Alice clicks the SW login link, she is redirected to the SW login page. After validating her credentials, 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 email is used to identify users in the AA system (which is a common practice), the AA application requests Alice’s email address from SW using the session code provided, along with a secret code. This secret code was generated when the AA developers registered their application with SW, ensuring that it is the legitimate AA application making the request and not an unauthorized entity that intercepted the session code.
Once the email address is received, AmazingApp can identify Alice and provide access based on her role and permissions. If the email address doesn’t exist in the AA database, Alice is registered as a new user.
Alternatively, the AmazingApp could register users based on their social media IDs. However, because these IDs are not standardized across platforms (e.g., a LinkedIn user ID looks like “H0i-5zIMye” while a Facebook user ID looks like “9495390900803521”), email addresses are the most common denominator used by applications.
Addressing Security Concerns
Now back to the question: Is it safe, or does it potentially give SocialWonder full access to Alice’s AmazingApp account?
In theory, it’s possible. For example, SW could initiate a login to AA and return a session code without requiring Alice’s password. The AA application would then use the session code to request Alice’s email address and identify the user. If SW provides the email address of an account it wants to access, it could potentially gain unauthorized access. However, this scenario is highly unlikely. Such behavior would be discovered quickly, and SocialWonder’s credibility would be destroyed overnight.
Is Third-Party Authentication a Good Idea?
In most cases, yes. Third-party authentication provides convenience and efficiency by reducing the need to remember multiple usernames and passwords. However, users must ensure their third-party accounts are secure. If a third-party account is compromised, all websites relying on it for authentication become vulnerable.
To mitigate risks, users should:
– Use strong, unique passwords for their third-party accounts.
– Enable multi-factor authentication (MFA) where available.
– Regularly review and revoke access for unused applications.
By diligently securing their main accounts, users can enjoy the benefits of third-party authentication without significant risk.
To enable third-party user authentication, the website or application developer must register the application with the third party. Upon registration, the developer receives a Client ID (or app code) used to identify the application during user login, and an application secret, which is used to authenticate the application. This secret must remain confidential, and a new one should be requested immediately if abuse is suspected.
