Protecting End User’s Privacy When using Social Login

through GDPR Compliance

Carlos Villar

an and Marta Beltr

Department of Computing, ETSII, Universidad Rey Juan Carlos, Madrid, Spain

Keywords:

GDPR, Identity and Access Management, OpenID Connect, Privacy, Social Login.

Abstract:

Social login allows end-users to identify and authenticate in different applications and services using their

social network providers (Facebook, Twitter, Google, LinkedIn) instead of using speciﬁc accounts and pass-

words. This kind of single-sign-on approach relies on federated identity management speciﬁcations that sig-

niﬁcantly simplify login processes. However, this kind of solution also implies new threats for end user’s

privacy, because identity providers (social network providers) have access to sensitive information that allows

them to perform processing without explicit consent (to proﬁle or track their users, for example) or that can

be shared with third parties. This paper proposes the inclusion of new capabilities within the authentication

ﬂows, intending to mitigate these privacy threats guaranteeing compliance with the General Data Protection

Regulation (GDPR) through transparency and efﬁcient use of already existing mechanisms and technologies

such as back-channel logout or consent receipts. Furthermore, the integration of these capabilities in OpenID

Connect ﬂows has been validated with a real prototype of the proposed solution.

1 INTRODUCTION

Social network providers have become identity

providers. Federate identity management speciﬁ-

cations such as SAML (OASIS Security Services

(SAML) Technical Committe, 2005), OAuth (Inter-

net Engineering Task Force (IETF), 2012) or OpenID

Connect (OpenID Foundation, 2014) enables single-

sign-on procedures. Once an end-user has logged

at the social network, this account can be used to

authenticate to third-party applications and services

smoothly. This approach reduces the number of ac-

counts and passwords an end-user has to deal with,

improving at the same time usability and security.

Although identiﬁcation and authentication proce-

dures are transparent, and users’ experience is com-

fortable (it consists of a click in a button), this kind of

social login may have a signiﬁcant impact on privacy

(Scott et al., 2016). End-users provide sensitive infor-

mation to identity providers (static personal data, dy-

namic contextual data), and these providers may share

this information with other providers or third parties

(without users’ knowledge or consent), may leak it in-

voluntarily or may use it to proﬁle or track them with

commercial objectives.

The protection of end-users’ privacy in these sce-

narios and the compliance with current regulations are

still an open problem because aforementioned feder-

ated speciﬁcations do not include speciﬁc capabilities

or features regarding data protection.

The main contributions of this work are: 1)

A novel approach for protecting end-users’ privacy

when using federated mechanisms to solve iden-

tity management. The proposed solution enables

compliance with the GDPR with independence from

the identity provider and the application or service

provider. 2) The identiﬁcation of the speciﬁc capa-

bilities that must be added to social login implementa-

tions to guarantee each of the rights set out in this reg-

ulatory framework. 3) The adoption of the proposed

capabilities through the use of an uniﬁed and stan-

dard web portal and well-known and widely adopted

technologies and mechanisms, easily integrable with

current federated speciﬁcations used for social login.

Mainly, back-channel logouts and consent receipts.

The rest of this paper is organized as follows. Sec-

tion II provides an overview of the background on un-

derlying concepts and the related work. Section III

discusses the primary motivations for this work with

some examples and potential use cases. Section IV

describes the proposed approach to add privacy ca-

pabilities to federated identity management speciﬁca-

tion capable of guaranteeing GDPR compliance. Sec-

tion V details the proposed solution implementation,

428

Villarán, C. and Beltrán, M.

Protecting End User’s Privacy When using Social Login through GDPR Compliance.

DOI: 10.5220/0010521304280435

In Proceedings of the 18th International Conference on Security and Cryptography (SECRYPT 2021), pages 428-435

ISBN: 978-989-758-524-1

validation and evaluation. Finally, Section VI sum-

marizes our main conclusions and the most interest-

ing lines for future research.

2 BACKGROUND AND RELATED

WORK

2.1 On Federated Identity Management

Federated identity and access management involve

an end-user who needs to be authenticated or autho-

rized to access an application or service. Instead of

forcing this application or service to solve authenti-

cation/authorization by itself, this last agent and the

end-user rely on an external server, delegating the

primary responsibilities to this third-party provider.

Identity providers can work within trust federations,

summarizing claims about the authenticated user and

her privileges in a standard format, a capacity or to-

ken.

The most adopted federated speciﬁcations are

SAML for authentication, OAuth for authorization

and OpenID Connect/Mobile Connect for authentica-

tion and authorization (with only one ﬂow, this is why

it is the basis of almost all social login solutions).

Using the most complex ﬂow as an example (ﬁg-

ure 1), the proposed by these last speciﬁcations, when

an end-user needs to access an application or service

(step 1), this agent, the Relying party or RP, redi-

rects her browser to the Identity Provider or IdP (step

2). This provider is responsible for authenticating the

end-user or obtaining her consent to perform the re-

quested interaction if she has logged in already (steps

3 and 4).

After performing the authentication, the end user’s

browser is redirected back to the application or ser-

vice with and Authorization Code (steps 5 and 6).

This code is used to request a token (step 7 and 8)

that claims about the authenticated end-user (the ID

token) and an additional token that can be used to de-

termine the scope of the user’s privileges and to obtain

more information about her.

2.2 On Social Login and Privacy

In these federated speciﬁcations, social network

providers, technology companies, and mobile net-

work operators have found a mechanism to provide

a new service to their users: single sign-on for appli-

cations and services. For example, Facebook, Twit-

ter, Google or Apple allow their users to sign in to

a third-party provider instead of creating a new ac-

count speciﬁcally for that application or service. As

mentioned before, this simpliﬁes registrations and lo-

gins for end-users and improves their quality of expe-

rience. For providers, this kind of authentication and

authorization also has signiﬁcant beneﬁts; they avoid

bothering users creating new accounts, losing fewer

users during the registration or account resetting pro-

cesses, which increases the number of visitors.

On the other hand, identity providers offer this

social login service, very often free, because users’

data is precious. The collected information al-

lows providers to improve their content and services

(through personalization), their ability to place tar-

geted advertisements, etc. Therefore, not keeping any

information about the authentication activities of their

users (an easy way to become GDPR-compliant) is

not an option.

Different researches have emphasized in the pri-

vacy threats that this social login poses to end-

users. Some of these works apply different threat

modelling methodologies and techniques (Robles-

Gonz

alez et al., 2020) to conclude that the main pri-

vacy threats observed when using social login are per-

sonal data leakage, lack of control over personal data

at the identity provider, lack of transparency in the

sharing of personal data, end-user proﬁling or end-

user location tracking.

Previous works try to mitigate all these threats

proposing speciﬁc countermeasures or mitigations.

The ﬁrst threat can be mitigated or even avoided im-

proving the security of the speciﬁcations and its im-

plementations at the identity provider infrastructure.

Different works have focused on this research area

such as (Mainka et al., 2017), (Fett et al., 2017), or

(Li and Mitchell, 2020).

Other works such as (Bodnar et al., 2016), (Vil-

larreal et al., 2017) or (Navas and Beltr

an, 2019),

propose solutions for the second and third threats,

trying to minimize the personal data required when

registering at an identity provider and improving the

transparency of information-sharing processes as well

as the control provided to end-users. These works

rely on concepts such as privacy scopes to be agreed

by end-users when sharing their personal data with

third parties privacy tokens to exchange privacy pref-

erences or reputation schemes designed to quantify

the degree of privacy protection achieved by the dif-

ferent providers. Even there are works proposing

experiments to explore end users’ privacy awareness

when using login methods or developing tutorials and

awareness campaigns to inform them on the pros and

cons ((Moey et al., 2016), (Farzaneh Karegar and

Fischer-H

ubner, 2018)) or helping the users to scan

vulnerabilities when they use OpenID via web plugin

(Li et al., 2019).

Protecting End User’s Privacy When using Social Login through GDPR Compliance

429

Figure 1: Authorization Code ﬂow using OpenID Connect.

On the other hand, (Fett et al., 2015), (Isaakidis et al.,

2016) and (Hammann et al., 2020) focus on guaran-

teeing unlikability in order to avoid user proﬁling or

tracking (threats fourth and ﬁfth in the provided list).

It has to be pointed that the last group of works

((Asghar et al., 2016), (Halpin, 2017)) proposes a

complete change in the concept of federation, letting

identity providers issue credentials and tokens that

end-users store locally. These users use these cre-

dentials and tokens when they need to access applica-

tions, and services without any interaction with iden-

tity providers. Therefore, keeping control over their

personal data.

3 MOTIVATION AND USE CASES

Different research results show how their sensitive

information’s privacy is an important issue for end-

users. However, most of them rarely make an ac-

tive effort to protect this information; on the contrary,

they tend to give it away voluntarily if they can get a

beneﬁt in return. This is known as the privacy para-

dox, and it is one of the main motivations of this re-

search because it has been rarely considered in previ-

ous works. Some providers may have already created

the infrastructure needed to be compliant with GDPR

and to provide their users with tools to exercise their

rights. But these tools are rarely known by users, un-

derstandable, usable, complete, interoperable or well

integrated with the technology that supports the au-

thentication processes.

We think that the capabilities necessary for GDPR

compliance must be built into the IdP, from design,

following standard frameworks (to avoid end-users to

handle one new solution for each speciﬁc provider),

and provided in its default implementations, not just

when users request them. Other limitations identiﬁed

in these previous works can be summarized in:

• Ease of adoption and integration. Many of the

mentioned works propose solutions that involve

signiﬁcant changes to current speciﬁcations or

their implementations. This makes their adoption

very difﬁcult, so they are not usually deployed

in production environments. Another important

adoption barrier is that in many cases, they are

based on the development of custom solutions and

components rather than standard technologies or

mechanisms widely used by development teams

that have to integrate identity management into

their products.

• Compliance with regulation. Previous works usu-

ally propose improvements that increase the levels

of privacy provided by social login mechanisms

but do not guarantee that these comply with cur-

rent regulations such as the GDPR in the case of

Europe. This makes its adoption very complicated

in many contexts in which this type of data protec-

tion regulations has been obligatory for a couple

of years now.

• Regarding the compliance with the regulation, the

end-user’s consent to carry out any processing ac-

tivity is essential. However, most of the previ-

ous works in this research area do not address this

consent’s management at all.

The main goal of this research is to overcome all these

limitations. Current identity providers are often fail-

ing to fulﬁl explicit end-user requests (without undue

delay) to guarantee their rights under the GDPR be-

cause of the already mentioned limitations of speciﬁ-

cations and their implementations. This failure may

cause a complaint to supervisory authorities and a re-

sult of a large ﬁne or reputation loss.

The most important use cases that may beneﬁt

from the proposed solution, are those exempliﬁed in

the following scenarios:

SECRYPT 2021 - 18th International Conference on Security and Cryptography

430

Scenario 1. An end-user wants to Facebook con-

nect as her primary login alternative at different ap-

plications. This end-user is concerned about her pri-

vacy, and she would like to be informed: What types

of personal data is Facebook processing? Which is the

lawful basis for this processing? How long will this

provider be storing this data? Will Facebook share

this data with other organizations? What visibility

will have the user about this data sharing? Further-

more, the user wants the right to access (to obtain a

copy) and to rectify (to correct inaccuracies) this data.

Scenario 2. A European end-user wants to use Sign

In with Apple to perform social login at different ap-

plications and services. Nevertheless, she wants to

object to direct marketing or restrict it (or other types

of processing at the identity provider or a speciﬁc re-

lying party), take her data to another identity provider

(including historical data about information shared

with RPs), or erase her data at any moment.

Scenario 3. A SaaS company relying on GSuite

would like to simplify employees’ authentication us-

ing Google Sign-In to perform social login at all the

corporate apps and services (collaboration, market-

ing, development, etc.). However, this company re-

quires precise control over shared information and de-

tailed traceability of information shared with RPs. For

example, to perform an audit or to demand account-

ability in case of a data breach.

4 A MODEL FOR GDPR

COMPLIANCE WITHIN

SOCIAL LOGIN SOLUTIONS

4.1 GDPR Roles and Rights

The GDPR (Parliament and Council, 2016) is the cur-

rent data protection regulation in Europe, designed to

guarantee greater privacy protection and rights to Eu-

ropean citizens and to harmonise data protection laws

across all European countries. It is currently consid-

ered the world’s strongest data protection regulatory

framework.

This regulation distinguishes ﬁve different roles

regarding data protection. The ﬁrst is the Data Sub-

ject, the natural person who is the owner of the per-

sonal data which identiﬁes him or her or enables him

or her to be identiﬁed. Within a social login solution,

the Data Subject is an European end-user.

The second is the Data Controller, the natural

person or legal entity that decides the purposes and

mechanisms of the processing of personal data. The

controller is accountable for GDPR compliance. The

third is the Data Processor, a third party (natural per-

son or legal entity) that processes personal data on be-

half of the Data Controller. The processor must fulﬁl

the conditions speciﬁed by the controller in a signed

Data Processing Agreement (the mechanism used to

guarantee that obligations stated in GDPR are com-

plied with).

Within social login solutions, the Data Controllers

are the IdP and RP and the Data Processor are also the

IdP and the RP or even a third party not included in

the authentication ﬂow.

The fourth is the Supervisory Authority, a public

organization in an European country responsible for

monitoring compliance with GDPR: advising compa-

nies, auditing their compliance, managing complaints

from Data Subjects, etc. Since identity providers op-

erate in multiple European countries, these companies

usually choose to appoint a Lead Supervisory Author-

ity for the purpose of reporting. In this way, they sim-

plify compliance management, reporting, etc.

The last one is the Data Protection Ofﬁcer (DPO),

that is not always present (it is not mandatory for cer-

tain companies). This ofﬁcer is the person responsible

for ensuring compliance with GDPR, advising com-

pany management and staff about the best strategy to

follow and it implementation. Identity providers must

appoint a DPO because they process personal data of

European citizens at a large scale.

All end-users have GDPR rights that the IdP and

RP have to guarantee, but currently, the Data Subject

has to request the Data Controller this fulﬁlment ex-

plicitly. The Data Subject rights within the GDPR are

the right to be informed, right of access, right to ob-

ject, right to rectiﬁcation, right to erasure (right to be

forgotten), right to restriction of processing, right to

data portability and right not to be subject to a deci-

sion based solely on automated processing. The last

one does not apply in social login scenarios.

The right to be informed (articles 13 and 14 and

recitals from 60 to 62) allows end-users to know

who is the IdP or RP and how to contact them (their

DPO); the purposes and interest of the performed data

processing; recipients and international personal data

transfers and the retention period.

The right of access (article 15 and recitals 63

and 64) allows end-users to request the IdP and RP

an intelligible copy of the personal data they have

collected about them and other supplementary infor-

mation. Without undue delays and without being

charged any fee.

The right to object (article 21 and recitals 69 and

70) enables end-users to oppose data processing when

Protecting End User’s Privacy When using Social Login through GDPR Compliance

431

there are no legitimate grounds. The right to rectiﬁ-

cation (article 16 and recital 65) allows end-users to

request a personal data correction to the IdP or RP

when this personal data is incomplete or inaccurate.

The right to erasure, also known as the right to

be forgotten, (article 17 and recitals 65 and 66) can

be exercised when the end-users’ personal data is

no longer required at a provider, when the end-users

withdraw their consent when data processing is il-

licit or due to legal compliance and after exercising

the right to object when there are no other legitimate

grounds.

There is an alternative to requesting the erasure of

personal data: restrict the processing in certain cir-

cumstances (article 18). This right can be exercised

to limit the way that the IdP or the RP use data if the

end-user has a particular reason for asking for this re-

striction. The restriction is usually in place temporar-

ily.

Finally, end-users have the right to data portabil-

ity (article 20). Therefore, to obtain data that the IdP

or RP store and reuse it for their own purposes, for

example, move it to a new provider.

4.2 Privacy Capabilities Required for

GDPR Compliance

Taking into account the rights discussed in the previ-

ous section, the capabilities that the IdP must incor-

porate to ensure that they are fulﬁlled can be sum-

marised in three:

1. Centralised information repository where the end-

users can see their personal data and other in-

formation related to them and can exercise their

rights. This repository has to be user-friendly, up-

to-date and concise in order to help users to under-

stand their rights and assist them in the process of

exercising them. Furthermore, the IdP and RP can

easily comply with their obligations of facilitat-

ing the end-users’ right exercise (recital 59), serv-

ing information about the end-user data process-

ing (recital 61) and providing secure remote ac-

cess to end-users’ personal data (recital 63). The

IdP and RP have, in a centralized manner, all the

necessary information to inform their users or to

quickly transfer the information to other IdPs or

RP if needed.

2. Ability to revoke tokens, forcing the logout of an

RP from an IdP, without needing end-user inter-

vention.

3. Use of consent receipts, standard documents that

summarize what personal data has been given,

to whom (IdP, RP or third party), and for which

purposes. These receipts must be stored in the

centralized information repository, written in a

machine-readable format and available for down-

4.3 Improvements in Social Login

Implementations

This work proposes a uniﬁed (and standard) web por-

tal offered by the IdP to comply with the GDPR

rights, it is the easiest way to maintain (from the IdP

point of view) and to consult (from the end-user point

of view) the required centralised information reposi-

tory.

Within the social login solutions, the IdP has to

perform some actions to guarantee the GDPR rights’

fulﬁlment. Regarding the right to be informed, this

work proposes that the uniﬁed web shows all the re-

quired information by this right, including advice. Af-

ter the end-user clicks on this right, the uniﬁed web

explains it, pointing that all the information needed is

included in the previous screen. This repository has

to inform the user about collected personal data, re-

tention period and data source, data processing and

grounds, recipients and international transfers and IdP

and RP information, including their DPO. Also, it

has to store consent receipts and logs with exercised

rights. This helps the end-users to follow their re-

quests and know if they were accepted or not. More-

over, there should be an available trace of when has

the IdP performed the actions to comply with the

rights.

Regarding consent receipts, the Kantara Consent

Receipt Speciﬁcation is recommended in this work

(Kantara Initiative, 2018). Following this speciﬁca-

tion the receipt is human-readable and can be repre-

sented as a standard JSON, both aspects very advanta-

geous in the context of social login. On the one hand,

end-users will be able to consult the receipts if they

wish to do so. On the other hand, the JSON format is

already used in the speciﬁcations of the authentication

ﬂows, so it will be easy to handle (read, write, update,

store, transmit) for the IdP and the RP.

This work proposes a similar solution for the right

of access, showing all the needed information for this

right in the uniﬁed web. All the information for both

rights also gives the chance to understand better how

the IdP and RP manage the end-user personal data. As

explained in the information right, after the end-user

clicks on the right of access, he or she is informed

about this right, pointing that all the information is on

the main screen of the uniﬁed web.

This work proposes that once the end-user has

selected the right to object on the main screen,

SECRYPT 2021 - 18th International Conference on Security and Cryptography

432

its explanation is shown. In the next screen, the

end-user can select the data processing he wants to

object. Some of these data processing could not

be chosen if legitimate grounds exist that overrides

end-users right, but the web has to clearly explain

those grounds. Once the end-user has selected the

data processing he wants to object; the IdP has to

manually check the request or use an automatic

process. After that, the IdP (or RP) has to change the

scopes of the ID token. First, this work proposes to

perform a back-channel logout (Foundation, 2020)

with those RPs that have in place the data processing

the end-users are objecting to. As it has been

mentioned before, this capability forces the logout

of an RP from an IdP, without needing end-user

intervention. Before starting this ﬂow, the RPs must

be registered in the IdP, including their back-channel

logout URI (step 0 of ﬁgure 2). In the ﬁrst step of

the back-channel logout ﬂow, the IdP sends an HTTP

POST to the RPs back-channel logout URI with a

logout JSON Web token or JWT (step 1 of ﬁgure 2).

This logout token includes the logout event (”events”:

”http://schemas.openid.net/event/backchannel-

logout”: ) and a reference to the affected end-user.

This reference can directly identify the user, in-

cluding the subﬁeld, the end-user session (sid ﬁeld)

or both. The RPs, after validating the logout JWT

has to perform the end-user logout (step 2 of ﬁgure

2), taking into account the recommendations of

(Foundation, 2020). Each RP responds to the IdP

(step 3 of ﬁgure 2) with an HTTP 200 OK if the

process was successful or with an HTTP 400 Bad

request otherwise. Besides, the RP can respond an

HTTP 501 Not implemented if the logout process

fails. A similar approach should be used with the

right to restrict processing.

Regarding the right to rectiﬁcation, within the so-

cial login scenario, the personal data is stored in the

IdP, so the data correction must be done in the IdP.

This work proposes that the uniﬁed web lets the end-

user directly correct them in the IdP. After select-

ing this right on the main screen of the uniﬁed web,

the end-user can read an explanation of this right. It

should include that this process could force a logout in

those RPs that uses the personal data that need to be

corrected (to avoid these RPs using an obsolete ver-

sion of this data). After that, the end-user can correct

his data. Once he has ﬁnished and moved to the next

screen, the IdP can validate if this personal data is cor-

rect. This validation can be done with an automated

process or manually. An example of an automated

process can be entering a code sent via email or SMS

to check that the email or mobile phone, respectively,

is correct. A manual process can be performed by an

agent calling the end-user to check the correction. Af-

ter the validation screen, the user returns to the main

screen. If the modiﬁed personal data is also stored in

JWT, the IdP could wait for the JWT expiration and

correct the personal data in the reissuing process. If

the expiration time is too long, the IdP has to force

a back-channel logout following the same ﬂow as in

the right to object. The end-users can see on the main

screen when the personal data has been updated.

This work proposes that after selecting the right to

erase or the right to be forgotten, the end-user can read

an explanation of the right. This explanation has to in-

clude information about how much time is needed to

complete the process, including backups of personal

data. In the next screen, the end-user can select the

personal data he wants to delete. Some personal data

could be not selected when the end-user does not have

the right to erasure that personal data, but an explana-

tion of the grounds needs to appear. After that, the

end-user return to the main screen and the IdP can

process the request with undue delay using an auto-

mated process or manually. Once it is conﬁrmed that

the end-user has the right to delete the personal data,

the IdP performs a back-channel logout in those RPs

that uses the personal data. After that, the IdP can

delete the personal data following their own proce-

dure. Also, it has to remember to erasure the data

from backups if feasible because backups can contain

this type of information. The end-users can see the

deletion of their personal data on the main screen of

the uniﬁed web.

With the right to portability, the end-users can ob-

tain a structured and processable ﬁle with their per-

sonal data. This work proposes that after selecting

this right on the main screen, the end-users can read

an explanation of this right. After that, the end-

users can select between transferring the information

to other integrated entities with the IdP or download-

ing a ﬁle, in a standard format, with the content. Fi-

nally the end-users return to the main screen.

5 IMPLEMENTATION AND

VALIDATION

5.1 Prototype

The prototype implementation is based on HTML,

JavaScript and PHP in a XAMPP server over Win-

dows 10. It also uses JSON as structured format for

data (compatible with current social login speciﬁca-

tions and implementations). It has been implemented

within an OpenID Connect IdP, the basis of all current

Protecting End User’s Privacy When using Social Login through GDPR Compliance

433

Figure 2: Back-channel logout ﬂow.

social login implementations (Facebook, Google, Ap-

ple, etc.).

The uniﬁed web portal shows the information in

tabs. The ﬁrst tab includes the end-users’ personal

data, consent receipts, retention period and source.

The second tab shows performed data processing and

grounds. The third tab incorporates recipients and in-

ternational transfers. The fourth tab includes IdP and

DPO information. The last tab contains a log of the

exercised rights, including the affected personal data

or data processing, when was the request, and when

was the resolution. At the bottom of this web, there is

a form where the user can make a new request.

5.2 Validation and Discussion

From a functionality perspective, the proposed solu-

tion provides IdPs mechanisms to fully comply with

the GDPR. This is due to the following reasons:

• Guarantees lawfulness and fairness: The pro-

posed uniﬁed web portal allows end-users to ex-

ercise their applicable data protection rights in the

same standardised way in all their IdPs. The three

scenarios introduced in section 3 can be solved

with GDPR compliance thanks to the informa-

tion available within the portal, the permission to

edit (to update or to erase, including backups) or

download data (to access or to move to another

provider) and the capacity of objecting to or re-

stricting data processing (including the ability to

revoke alive tokens already provided to RPs).

• Facilitates security, transparency and accountabil-

ity: If the end-user authentication performed by

the IdP is assumed to be secure, the proposed

mechanisms are secure, because only properly au-

thenticated and authorised users are allowed to ac-

cess the uniﬁed web portal. The additional infor-

mation included in this portal, such as explain-

ing the users rights or the DPO contact data im-

proves transparency. Finally, the logging of exer-

cised rights and the recording of consent receipts

increase accountability.

The prototype demonstrates that the proposed solu-

tion constitutes a valuable tool to allow individuals

to exercise their rights in social login scenarios with-

out requiring changes in current federated identity

management speciﬁcations. But this kind of user-

centric privacy-enhancing technology requires further

research in two aspects. The ﬁrst is to ﬁnd incentives

to IdPs to provide this kind of tool. The most essential

incentive should be to foster the competition of digi-

tal services, but current providers do not perceive that

they need to offer this kind of control to their users to

win this competition. It is much more likely that their

motivation, at present, is related to avoiding the ﬁnes

mentioned in section 3. The second is to ﬁnd incen-

tives to end-users to reclaim this control, understand

the value of their data, and be able to use a tool such as

the one proposed in this paper to exercise their rights

and enjoy the mentioned value.

6 CONCLUSION

GDPR is a legal document that provides no techni-

cal guidance to the entities that have to comply with

it. This is one reason why current social login solu-

tions (provided by non-European companies in most

cases) are not aligned with this data protection regula-

tion, although many of the users of these services are

European citizens.

This paper has introduced three main privacy ca-

pabilities, easy to implement and to integrate with

current authentication ﬂows, that can be used by

the IdP of these social login solutions to guarantee

GDPR-compliance. The ﬁrst, a simple, unambigu-

ous, intuitive and tailored to end-user needs uniﬁed

and standard web portal containing all the informa-

tion regarding applicable data protection rights (right

to be informed, right of access, right to rectiﬁcation,

right to erasure, right to restrict processing, right to

data portability and right to object). The second, the

ability to revoke alive tokens when the exercise of

these rights makes it necessary. And the third, the use

of standard consent receipts to keep a user-friendly

record of end-user consents for data collection and

processing.

A prototype of a solution based on the proposed

SECRYPT 2021 - 18th International Conference on Security and Cryptography

434

mechanisms has been implemented and used to val-

idate their functionality, demonstrating how an IdP

using OpenID Connect can easily guarantee GDPR

compliance (no change in the current speciﬁcations is

required and standard technologies and mechanisms

can be used), following the principles of lawfulness,

fairness, security, transparency and accountability.

REFERENCES

Asghar, M. R., Backes, M., and Simeonovski, M. (2016).

PRIMA: privacy-preserving identity and access man-

agement at internet-scale. CoRR, abs/1612.01787.

http://arxiv.org/abs/1612.01787.

Bodnar, L., Merkle Westphall, C., Werener, J., and West-

phall, C. (2016). Towards privacy in identity manage-

ment dynamic federations. In ICN 2016 : The Fif-

teenth International Conference on Networks.

Farzaneh Karegar, Nina Gerber, M. V. and Fischer-H

ubner,

S. (2018). Helping john to make informed decisions

on using social login. In Proceedings of the 33rd An-

nual ACM Symposium on Applied Computing, page

1165–1174.

Fett, D., K

usters, R., and Schmitz, G. (2015). SPRESSO:

A secure, privacy-respecting single sign-on

system for the web. CoRR, abs/1508.01719.

http://arxiv.org/abs/1508.01719.

Fett, D., K

usters, R., and Schmitz, G. (2017). The web SSO

standard OpenID Connect: In-depth formal security

analysis and security guidelines. In 2017 IEEE 30th

Computer Security Foundations Symposium (CSF),

pages 189–202. IEEE.

Foundation, O. (2020). OpenID Connect back-channel

logout 1.0. https://openid.net/specs/openid-connect-

backchannel-1 0.txt.

Halpin, H. (2017). NEXTLEAP: decentralizing identity

with privacy for secure messaging. In Proceedings of

the 12th International Conference on Availability, Re-

liability and Security, Reggio Calabria, Italy, August

29 - September 01, 2017, pages 92:1–92:10. ACM.

Hammann, S., Sasse, R., and Basin, D. (2020). Privacy-

preserving OpenID Connect. In Proceedings of the

15th ACM Asia Conference on Computer and Com-

munications Security, page 277–289. Association for

Computing Machinery.

Internet Engineering Task Force (IETF) (2012).

The OAuth 2.0 authorization framework.

https://tools.ietf.org/html/rfc6749.

Isaakidis, M., Halpin, H., and Danezis, G. (2016). Unlim-

itID: Privacy-preserving federated identity manage-

ment using algebraic MACs. In Proceedings of the

2016 ACM on Workshop on Privacy in the Electronic

Society, pages 139–142.

Kantara Initiative (2018). Consent receipt spec-

iﬁcation 1.1.0. https://kantarainitiative.org/ﬁle-

downloads/consent-receipt-speciﬁcation-v1-1-0/.

Li, W. and Mitchell, C. J. (2020). User access privacy in

OAuth 2.0 and openID Connect. In 2020 IEEE Euro-

pean Symposium on Security and Privacy Workshops

(EuroS PW), pages 664–6732.

Li, W., Mitchell, C. J., and Chen, T. (2019). OAu-

thGuard: Protecting user security and privacy with

OAuth 2.0 and OpenID Connect. In Proceedings of

the 5th ACM Workshop on Security Standardisation

Research Workshop, SSR’19, page 35–44. Associa-

tion for Computing Machinery.

Mainka, C., Mladenov, V., Schwenk, J., and Wich, T.

(2017). Sok: single sign-on security—an evaluation

of OpenID Connect. In 2017 IEEE European Sympo-

sium on Security and Privacy (EuroS&P), pages 251–

266. IEEE.

Moey, L. K., Katuk, N., and Omar, M. H. (2016). Social lo-

gin privacy alert: Does it improve privacy awareness

of Facebook users. In 2016 IEEE Symposium on Com-

puter Applications & Industrial Electronics (ISCAIE),

pages 95–100.

Navas, J. and Beltr

an, M. (2019). Understanding and mit-

igating OpenID Connect threats. Computers & Secu-

rity, 84:1–16.

OASIS Security Services (SAML) Technical Committe

(2005). SAML v2.0 standard. https://wiki.oasis-

open.org/security/FrontPage#SAML V2.0 Standard.

OpenID Foundation (2014). OpenID Connect.

https://openid.net/connect/.

Parliament, E. and Council, T. (2016). Regulation

(eu) 2016/679 on the protection of natural persons

with regard to the processing of personal data and

on the free movement of such data. https://eur-

lex.europa.eu/eli/reg/2016/679/oj.

Robles-Gonz

alez, A., Parra-Arnau, J., and Forn

e, J. (2020).

A LINDDUN-based framework for privacy threat

analysis on identiﬁcation and authentication pro-

cesses. Computers & Security, page 101755.

Scott, C., Wynne, D., and Boonthum-Denecke, C. (2016).

Examining the privacy of login credentials using web-

based single sign-on-are we giving up security and

privacy for convenience. In 2016 Cybersecurity Sym-

posium (CYBERSEC), pages 74–79. IEEE.

Villarreal, M., Villarreal, S., Merkle Westphall, C., and

Werner, J. (2017). Privacy token: A mechanism for

user’s privacy speciﬁcation in identity management

systems for the cloud.

Protecting End User’s Privacy When using Social Login through GDPR Compliance

435