translated from Spanish: The price we pay for signing in with Facebook or Google in apps

How many passwords does an average user use throughout the day? ¿50? ¿100? And all of them are supposed to be different, long, complex enough, not related to their life, etc. All this to make them safe and an attacker cannot guess or reuse them if you find out or steal them.
To save them work, in recent years a lot of work is being done to offer users solutions that allow them to authenticate (prove who they claim to be) when they need to use a resource, application or web service, usually from their computer or mobile.
Identification via Facebook and Google
One of these solutions is federated schemas for access management. They are called federated schemes because they are based on building trusted federations: end users and providers of the resources, applications, or services they want to access (an e-commerce store, the bank, the web to make an appointment with the doctor) rely on identity providers.
Alternatives to log in to a website.
Author provided provided
Today, these identity providers are almost always the big tech companies where most users have an account: Google, Facebook, Twitter, LinkedIn and Apple. In fact, sometimes we talk about social login.
In this way, to access any service (outside those companies), it is sufficient for the user to authenticate, usually with a password, to the identity provider. That is, you can register or sign in through Google, Apple or a social network so that you don’t have to create a new account and its corresponding key.
How can they act as intermediaries?
It has been years since Facebook and company collaborated with a consortium called the OpenID Foundation to propose a standard that would allow to resolve user authentication on the Internet in a federated way. This standard is called OpenID Connect, and is in its version 1.0 since 2014.
Thanks to this specification when, for example, we are going to buy a plane ticket and we have to identify ourselves on the website where we are making the purchase, we will usually be given two options.

The first, have a local account on that website with your own password. We’ll have to create it, or if we already had it, remember the password that we put in the moment.
The second, enter comfortably with our Google account, Facebook, etc. Just click on a button on the web. If we have not logged in to this provider, we are asked to do so at this time. If we’re already logged in, we’re usually already authenticated and can continue with the purchase directly.

Almost all users have become accustomed to making this second gesture in recent years. It saves them having to run an account for every service they use. This is especially useful in services that are used only once or very sporadically.
It should be mentioned that a little after OpenID Connect was standardized, telephony operators also wanted to take on the role of identity provider. For this reason, Mobile Connect was proposed, which is based on the same ideas and concepts, but associating the user with their phone number instead of a password. In this way, the operator would be the one who allows authentication.
A free service?
One has to wonder why so many companies from different sectors are offering to operate as identity providers. Apple, which was one of the few that had been left out of all this, launched its own solution last year.
In principle, they do it for free. We might think that they do so to improve the usability of the web and to favor the use of different types of resources, services and applications securely – they can give more guarantees than thousands of other companies that offer their services online but are not experts in resolving user authentication. After all, by improving the user experience and generating business on the Internet, they benefit, even indirectly.
But we might also think that managing the authentication of millions of users requires an infrastructure and an effort that is not fully compensated with this improvement in the functioning of the internet. Obviously, the answer is in the data.
Risks to users’ privacy
Every time we choose to use an identity provider to authenticate, our privacy can be threatened by differentminds. They can be summarized in these five:

Lack of control over our personal data. Almost all identity providers require a series of user personal data in order to enjoy federated authentication. This data must be provided and is identifying; allow us to associate our digital identity (on the internet) with physics (in the real world): first name, surname, phone number, etc.
Lack of control over the sharing of our personal data with third parties. In almost all authentication flows, the service accessed by the user can ask the identity provider for the user’s data. This is very convenient, for example, to autofill forms (with our name or our address for a shipment). But it also allows the store or the clinic, with the examples we mentioned earlier, to know who the user really is. And without this explicit intervention or account in most cases, this sharing of information is done automatically. It is a communication between the service you access and the identity provider.
Personal data leak. Once there is personal data of the user (which also allows to identify him/ stored in the identity provider and the services he has accessed, it may not be adequately protected and involved in a data breach. Compromised the user’s account at the identity provider, for example, all accesses that you have made through it are compromised.
Profiling. The identity provider can get a lot of information about each user. Know what you access at all times, from which device, etc. This allows you to get to know users better, their tastes, habits, interests, schedules. We all know how valuable this information is today for most companies.
Geolocation. The identity provider can obtain information about the location of users (via GPS information, but also from the IP addresses, Wi-Fi networks or apps they have installed on their devices) on each access they make. This valuable information is used to complete your profile.

Conclusions: should we trust each other?
Federated solution-based authentication—using Google, Facebook, Apple, and company as identity providers, is very convenient. It improves the user experience, saves them time and effort and can be more secure compared to using weak passwords.
But you have to take into account the risks to privacy. The service offered by these identity providers, as happens so often, is not free (or not entirely). Users pay for it with their data.
In this sense, some websites and applications have stopped offering their users the possibility to authenticate in this way in an attempt to protect their privacy or not to give other companies such valuable data.
In addition, more and more researchers and user groups are proposing solutions that allow us to work with these types of providers in a more privacy-friendly way. But the first step is for users to demand this respect, so identity providers will incorporate privacy from the design using encryption, disengagement and offering greater transparency.
Marta Beltrán, Professor and Coordinator of the Bachelor’s Degree in Cybersecurity Engineering, Universidad Rey Juan Carlos and Jorge Navas Diaz, PhD in Cybersecurity, King Juan Carlos University
This article was originally published in The Conversation. Read the original.

Original source in Spanish

Related Posts

Add Comment