Third-party authentication (OAuth): Good or bad for security?
There is a reasonable probability that anyone reading this will have set up an online account that uses Google, Facebook or other social media login for authentication. Social media-authenticated login options are convenient for users and web developers alike. Furthermore, social media logins are used not only to access online accounts but also to provide access to IoT devices, smart TVs, and other devices. But does this convenience cost us security?
When Facebook went down in 2021, countless millions lost access to accounts authenticated using their Facebook login. So the questions are: Has this experiment with third-party authentication worked? And is it good, bad, or indifferent to secure login?
ChatGPT training built for everyone
Traditional login services
Usability vs. security has always been a delicate balancing act. However, offering users the ability to log into websites and services using third-party authentication has become commonplace over the past few years – for example, the ability to log in with your Google or Facebook account. People like the ease of registration when a single sign-on (SSO) option, like Facebook Login, is offered. In a white paper by Annex Cloud on login best practices, 77% of users said they prefer to log in to an account using a social media option.
Login with a third party offers convenience for users because they will often already have an account with one of the common third-party login providers. For organizations, the need to handle authentication credentials and credential recovery is (seemingly) eliminated.
Conventionally, organizations offering cloud services handle logins using a username or email address and a password; a second factor is often required, such as a single-use code delivered to the user via email, text message or mobile app.
The web page submits credentials to a backend service that uses the username/email to look up the user in a database and verifies the password by transforming it through a one-way function and comparing it to the data stored in the user's account. If used, a second-factor code is generated and delivered to the user via a third-party SMS text or email gateway, which the user then submits for verification.
The site must also supply a secure mechanism to handle lost password recovery and second-factor failures.
Third-party login services
Often, a third-party provider offers authentication services. Commonly, the provider will be outside the organization, although some authentication providers offer on-premise options. Many social media platforms provide APIs so that developers can build in federated social SSO for their users. Social logins can be integrated easily into web and mobile apps because they use open standard protocols such as OAuth 2.0 or OIDC (OpenID Connect).
How does third-party authentication work?
Third-party authentication most commonly uses OAuth 2.0, a well-established authorization protocol. (Strictly, the system involves authorization, not authentication, because the user authorizes the provider to release identifying data to the service.)
The principle is that the user authenticates at the third-party provider alone:
- Starting at the service (or relying party, RP) the user wants to access, they are presented with a choice of third-party providers, e.g., Facebook, Google, etc.
- The user chooses one of these providers where they already have an account and are then redirected to that provider.
- The user logs in into the provider and consents to share their identity with the RP.
- The provider redirects back to the RP and eventually issues a token; the RP may then use it to access the user's data, including their unique identifier.
- The RP can then use that identifier to look up the user and grant access to the service accordingly.
Benefits of third-party authentication
Assuming the third-party system is well designed and implemented, its use by an RP has the following advantages:
- The user has fewer login credentials to remember or manage.
- The service (RP) is no longer required to store login credentials or handle secure credential recovery methods.
- The user does not share any credentials with the RP.
- The provider may offer out-of-band options for authorization, allowing the user to authenticate securely to an RP’s service face-to-face (e.g., retail store), over the phone (e.g., for an insurance payment) or via smart device (e.g., authorizing payment through a smart TV), by interacting with their provider on their mobile device without sharing credentials with the service.
Potential issues with third-party authentication
There are several areas where the use of third-party authentication can cause problems.
Security
The security of the service's accounts depends on the provider's security and the interaction between the service and provider. This may mean limiting the user's choice of providers to those that meet the service's security requirements, such as being able to supply verified identity data and secure communications with the provider, for example, through mutual transport layer security (MTLS). In addition, requiring a second factor may enhance weakly secured social login providers.
Availability and reliability
The Facebook outage of 2021 demonstrated how the dependence on a single point of failure, such as a social login API, can cause a massive ripple across the internet. Also, smaller social media providers may not be able to manage the bandwidth of millions of users logging on concurrently. The question remains: What if the social media provider goes out of business or changes hands, removing the ability to provide third-party authentication? This may seem a remote consideration, but it should be included in any long-term user management strategy.
Consent phishing
Malicious apps can trick users into revealing personal data using the OAuth 2.0 protocol. The problem stems from the OAuth 2.0 system not having a serious verification mechanism, thus allowing almost anyone to register an app with a provider. Once registered, the app can use the OAuth 2.0 authentication/authorization mechanism to request consented access to a user’s data.
Phishing simulations & training
Dealing with downtime
For an organization that relies on a third-party provider for user access, the provider becoming unavailable can have serious consequences. For example, when Facebook's servers became inaccessible on October 4, 2021, millions of users could not access sites that logged in with Facebook for several hours. A similar problem occurred with Google's OAuth 2.0 services in December 2020. As a result, social media platforms are interesting targets for cybercriminals. Social media authentication brings together a massive, distributed supply chain across millions of websites and IoT devices that rely on their APIs for user access. As a result, cybercriminals attacking a social platform can cause havoc across the entire web and in our homes.
There is a simple solution to the downtime implications of using a social media login — offer a choice: Do not rely on a single provider and enable users to log in or recover their access through multiple mechanisms; for example, offer codes sent via text message, email, etc.
Choice is always a good thing for consumers. Choice also provides a fallback mechanism and resilience for applications. It does mean additional work to add support for these extra options but compared to the support calls from large numbers of angry users, it will be worth the extra work to handle the situation of a social media site going down because of a cyberattack or outage.
Resources:
- ABC News, Facebook outage highlights risks of overdependence on a single tech giant
- Annex Cloud, social login platform best practices
- Infosec, Consent phishing: How attackers abuse OAuth 2.0 permissions to dupe users
- TechRadar, Google, YouTube and other services are down