Security of Mobile Single Sign-On: A Rational Reconstruction of

Facebook Login Solution

Giada Sciarretta

1,2

, Alessandro Armando

1,3

, Roberto Carbone

and Silvio Ranise

Security & Trust, FBK-Irst, Trento, Italia

University of Trento, Trento, Italia

DIBRIS, University of Genova, Genova, Italia

Keywords:

Single Sign-On, Digital Identity, Security of Mobile Devices, OAuth 2.0.

Abstract:

While there exist many secure authentication and authorization solutions for web applications, their adaptation

in the mobile context is a new and open challenge. In this paper, we argue that the lack of a proper reference

model for Single Sign-On (SSO) for mobile native applications drives many social network vendors (acting as

Identity Providers) to develop their own mobile solution. However, as the implementation details are not well

documented, it is difﬁcult to establish the proper security level of these solutions. We thus provide a rational

reconstruction of the Facebook SSO ﬂow, including a comparison with the OAuth 2.0 standard and a security

analysis obtained testing the Facebook SSO reconstruction against a set of identiﬁed SSO attacks. Based

on this analysis, we have modiﬁed and generalized the Facebook solution proposing a native SSO solution

capable of solving the identiﬁed vulnerabilities and accommodating any Identity Provider.

1 INTRODUCTION

Single Sign-On (SSO) protocols are arguably one of

the most successful security solutions available today.

They allow users to access multiple services through

a single authentication act carried out with an authen-

tication server acting as an Identity Provider (IdP).

Note that, by reducing the number of digital identities

(and credentials) a user has to deal with, SSO proto-

cols improve the user’s experience and security (e.g.,

stronger password selection).

While for web applications there exist many se-

cure authentication and authorization solutions to

protect the user’s digital identities and online re-

sources, solutions for mobile applications are not

yet consolidated. The existing protocols, such

as OAuth 2.0 (IETF, 2012a) and OpenID Con-

nect (OIDF, 2014a), provide only a partial support

for mobile native applications, leaving many imple-

mentation choices to developers. Leveraging these

protocols, many social networks have already de-

ployed their own authentication and authorization so-

lutions, which have been tremendously successful:

most Facebook and Google users routinely and trans-

parently use them on their smartphones and tablets.

However, the adaptation of protocols originally de-

signed to work in a traditional web scenario, to-

gether with the lack of a complete SSO standard for

mobile native applications (hereafter native SSO)—

it is only available a draft version released by the

working group NAPPS (OIDF, 2014b) of the OpenID

Foundation—have caused the spread of a number of

serious vulnerabilities and attacks. There are many

studies in the literature, such as (Chen et al., 2014;

Wang et al., 2013; Shehab and Mohsen, 2014), which

focus on the analysis and description of common vul-

nerabilities and attacks caused by incorrect imple-

mentation assumptions; however—to the best of our

knowledge—it remains unclear how to implement na-

tive SSO solutions in a secure way.

This paper provides a model which can be used to

support the native SSO development. More specif-

ically, we make the following three contributions.

First, we provide a rational reconstruction of the Face-

book

native SSO. Second, we include detailed secu-

rity considerations for the Facebook solution. Third,

we propose a native SSO solution inspired by the

Facebook native SSO but capable of solving the iden-

tiﬁed vulnerabilities.

In the rest of this paper we will focus on the SSO solution

used by Facebook. However the concepts discussed in this

paper can be easily adapted to the SSO solution developed

by Google.

Sciarretta, G., Armando, A., Carbone, R. and Ranise, S.

Security of Mobile Single Sign-On: A Rational Reconstruction of Facebook Login Solution.

DOI: 10.5220/0005969001470158

In Proceedings of the 13th International Joint Conference on e-Business and Telecommunications (ICETE 2016) - Volume 4: SECRYPT, pages 147-158

ISBN: 978-989-758-196-0

147

The rest of the paper is structured as follows. In

Section 2, we describe the basic notions of a SSO

scenario and, in the context of native applications,

we give a short overview of the OAuth 2.0 protocol.

We also provide an application scenario for the pro-

posed solution. In Section 3, we detail our rational

reconstruction and security analysis of the Facebook

solution. Together with the description of the ﬂow,

we make a comparison with OAuth ﬂows and explain

Facebook native SSO security issues. In Section 4,

we describe our solution for native SSO, comparing

it with the Facebook solution. Finally, we present the

related work in Section 5, and we draw our conclu-

sions and discuss our future work in Section 6. In

addition, in Appendix we detail the ﬂow of our native

SSO solution.

2 BACKGROUND

The goal of this section is to provide the basic notions

required to clearly understand the analysis performed

on the Facebook native SSO solution. Section 2.1

describes the entities involved and the functional re-

quirements of a SSO process. In Section 2.2, we give

an overview of the OAuth 2.0 protocol, used by Face-

book to perform the login process.

2.1 SSO: Entities and Requirements

SSO protocols allow users to access multiple services

through a single authentication act. The User partici-

pates in the protocol through a User Agent (UA) and

authenticates with an Identity Provider (IdP) with the

purpose of proving her identity to a Client entity (C).

We assume a SSO solution meets the following two

requirements:

(R1) the IdP user credentials can be used to gain ac-

cess to several Cs. This implies that users do not

need to have credentials with a C to access it.

(R2) If a user has already a login session with an IdP,

then she can access new Cs without entering her

IdP credentials anymore, and only the user con-

sent is required.

A typical SSO scenario consists of the following

steps: ﬁrst a user asks for access to C. Then C issues

an authentication requests to IdP (through UA). The

IdP authenticates the user and establishes a security

context with her. The IdP then sends an authentication

assertion containing the user information to C pass-

ing back through UA. Whenever in the future the user

will access new Cs through the same UA supporting

[HTTPS]

User

IdP

user&pw

Figure 1: SSO for Web Apps.

the login with the same IdP the login phase will be

skipped, thereby satisfying (R2).

The SSO entities are instantiated in different ways

based on the scenario and technology used. As we

will describe in Section 5, while the SSO scenario

where C apps are web application (illustrated in Fig-

ure 1) is very studied, the case where Cs are native

applications is quite new and challenging. For this

reason, in the rest of this paper we will focus on the

authentication process for Android

native apps.

2.2 OAuth for Native Applications

Many standards and products on authentication and

authorization have been developed in the last few

years by prominent organizations. Here we present

the OAuth 2.0 (OAuth, for short) (IETF, 2012a),

which is one of the most widespread protocols used

in the case of mobile native apps.

OAuth is an authorization protocol typically used

to manage delegation of authorization. To illustrate

consider a user, called Resource Owner (RO), which

wants to use an app, called Client (C), to print some

photos (resources) stored on a different photo-sharing

site (resource server). Using OAuth, RO can grant C

access to her private photos, without having to share

her credentials by directly authenticating with a server

trusted by the photo-sharing service, called Autho-

rization Server (AS), which issues an access token

to C carrying the requested authorization delegation.

The default access token type used in the OAuth pro-

tocol is a bearer token, which in (IETF, 2012b) is de-

ﬁned as “a security token with the property that any

party in possession of the token (a “bearer”) can use

We focus on Android, even if many concepts can be ap-

plied on other operating systems.

SECRYPT 2016 - International Conference on Security and Cryptography

148

1. RO login

2. Token request, RO credentials

3. access_token

Figure 2: OAuth RO Password Credential Flow.

RO UA C

1. Token request

2. user login + consent

3. redirect_uri#access_token

AS WHCR

4. redirect_uri

5. script

6. execute script

7. access_token

Figure 3: OAuth Implicit Flow.

the token in any way that any other party in posses-

sion of it can. Using a bearer token does not require a

bearer to prove possession of cryptographic key mate-

rial (proof-of-possession)”. This means that an entity

in possession of an access token can access the corre-

sponding RO resources without any further authenti-

cation and authorization process.

In many implementations, OAuth is also used for

authentication by assuming that the resource that C

wants to access is the user proﬁle on AS. If C can ac-

cess a user proﬁle, this means that the RO has granted

the permission. This authorization act is used by C as

a proof of the user identity.

In the case of native apps OAuth does not specify

which ﬂow to use. We have three possibilities: Au-

thorization Code, Implicit and Resource Owner Pass-

word Credentials. Note that, the Authorization Code

is the only ﬂow that requires the authentication of C.

Indeed, in the ﬁnal step of the ﬂow C exchanges a

code and its client secret to obtain an access token in

a direct communication with AS. The client secret is

a value obtained in the registration phase and known

only by itself. In the case of native apps, as every

information is visible by the RO (the owner of the

smartphone where the native apps are installed), the

conﬁdentiality of the client secret is not guaranteed.

These types of C, for which the client secret is not

conﬁdential, are called public Cs. Note that, if every

information pass through the RO’s smartphone, the

exchange of the client secret for an access token just

makes the ﬂow more complex without adding more

security. Thus, we will detail only the ﬂows designed

to be used with public Cs.

RO Password Credentials Flow. This ﬂow, illus-

trated in Figure 2, includes the following steps: in

Step 1, RO provides C with her own credentials.

Then, in Step 2, C requests an access token from AS’s

token endpoint by including the credentials received

from RO. Finally, in Step 3, AS validates the RO cre-

dentials, and if valid, issues an access token.

Implicit Grant Flow. This ﬂow, illustrated in Fig-

ure 3, involves the following steps: in Step 1, C initi-

ates the ﬂow by directing RO’s UA to the authoriza-

tion endpoint. C also includes a redirection URI to

which AS will send UA back once access is granted

(or denied). In Step 2, AS authenticates RO (via UA)

and establishes whether RO grants or denies C’s ac-

cess request. Assuming RO grants access, AS redi-

rects UA back to C (Step 3). The redirection URI

includes the access token in the URI fragment. In

Step 4, UA follows the redirection instructions by

making a request (which does not include the frag-

ment) to Web-Hosted Client Resource (WHCR). UA

retains the fragment information locally. In Step 5,

WHCR returns a web page (typically an HTML doc-

ument with an embedded script) capable of access-

ing the full redirection URI including the fragment re-

tained by UA. UA executes the script locally (Step 6),

which extracts the access token. In Step 7, UA passes

the access token to C.

2.3 Application Scenario

In this section, to motivate our work and give an illus-

trative example of the applicability of the proposed

native SSO solution, we describe an application sce-

nario that involves e-health mobile applications.

TreC (acronym for Cartella Clinica del Cittadino,

i.e. Citizens’ Clinical Record) is a platform

devel-

oped in the Trentino region for managing personal

health records. Besides the web platform, which is

routinely used by around 61,168 users since 2012,

TreC is currently designing and implementing a num-

ber of native Android applications to support self-

management and remote monitoring of chronic condi-

tions. These applications are used in “living lab” con-

text by voluntary chronic patients according to their

hospital physicians. An example is the “TreC-Lab:

Diario Diabete” app, which is a mobile diary that al-

lows patients to record health data, such as the blood

glucose level and physical activity. While in the tra-

ditional web scenario, patients access services using

The development of the platform is supported by a joint

project between Fondazione Bruno Kessler and Munici-

pality of Trento (Italy). More information is available at

https://trec.trentinosalute.net/.

Security of Mobile Single Sign-On: A Rational Reconstruction of Facebook Login Solution

149

User

FB_server

(IdP)

(a) Native Apps and Embedded Browsers.

User

FB_client (UA)

FB_server

(IdP)

(b) Native Apps Only.

Figure 4: Facebook Native SSO Solutions.

their provincial health care system credentials (lever-

aging a SAML-based SSO (OASIS, 2005) solution),

a solution for native SSO is currently missing.

The solution we propose will allow patients to

access different TreC e-health mobile applications

(and possibly other third-party e-health applications)

through a single authentication act with the provincial

health care system. In particular, the different entities

of SSO solution will be instantiated in the following

way: C apps will be the TreC e-health mobile appli-

cations, the User will be a patient that wants to use the

TreC apps to manage her health data, and the IdP will

be played by the IdP of the provincial health care sys-

tem. In addition, being the TreC data sensitive ones,

the proposed solution must be also ﬂexible enough to

support strong authentication mechanisms.

As we will show in the next sections, our solution

is an excellent starting point to fulﬁll the TreC needs

and accommodate the provincial health care system.

3 FACEBOOK NATIVE SSO: A

RATIONAL

RECONSTRUCTION

Facebook (FB, for short) exploits OAuth for both au-

thentication and authorization. In this paper, we will

focus on the authentication process for Android na-

tive apps, which allows app developers to integrate

the FB login feature, and so exploit the FB native SSO

solution. In Section 3.1, we describe the different

FB native SSO solutions identifying the scenario that

we will take into account during our security analy-

sis. Section 3.2 describes our rational reconstruction

of FB native SSO. Together with the details of the

ﬂow, we make a comparison with OAuth ﬂows. In

Section 3.3, we deﬁne the assumptions and the threat

model that we will use in the FB security analysis, and

ﬁnally, in Section 3.4, our security considerations on

FB solution are presented. The result of our analysis

shows that the FB native SSO is vulnerable to known

SSO attacks.

3.1 Facebook Native SSO Solutions

FB provides a Software Development Kit (SDK) to

help mobile app developers to implement the login

feature. As reported in the FB login guide (Face-

book, 2015), the SDK has two different kinds of login

implementation where the SSO entities are instanti-

ated in different ways: (i) in Figure 4(a), C

and C

are native apps installed on user smartphones, UAs

are embedded in the apps, and the IdP is played by

FB server; (ii) in Figure 4(b), C

and C

are native

apps installed on user smartphones, UA is a FB An-

droid app (hereafter FB client) handling user authen-

tication locally on the device, and the IdP is played by

FB server.

As pointed out in (Shehab and Mohsen, 2014)

and (Boyd, 2012), if an embedded browser is used

(case of Figure 4(a)), C has full control of the hosted

UA. Thus, if C is malicious, then it can steal the user

credentials or change the authorization permissions.

An additional limitation for the embedded browser

solution is that it does not satisfy the requirement

(R2). Indeed, if the browser is integrated within the

app, then the login session information is saved in

(and only accessible to) the app and it is therefore not

available to other apps. This forces the user to re-enter

credentials even if she has active login sessions with

For the sake of simplicity we consider only two Cs, the

generalization to more than two Cs is straightforward.

SECRYPT 2016 - International Conference on Security and Cryptography

150

FB_client

FB_server

app

User

1. click on login button

3. input credentials

4. token request, user credentials&sig

5. u_id & token_FB

7. token request, C_id&key_hash&u_id

8. user consent

10.

token_C

11. user info request, token_C

12.user info

StartActivityForResult

2. login

request,

C_id

9. token_C

6. read

key_hash

token_FB

Facebook

Figure 5: Facebook Native SSO Solution.

an IdP. We thus disregard this solution and take into

account the solution shown in Figure 4(b).

3.2 Facebook Flow Description

To reconstruct the FB native SSO solution, we im-

plemented an application that integrates the FB Login

feature following the FB documentation (Facebook,

2015) and using the FB Android SDK. At the time

of our analysis, we used Android 4.3.1, FB Android

SDK 3.22.0 and FB APK 23.0.0.22.14.

To obtain a precise description of the FB native

SSO ﬂow, we have performed the following method-

ology: (i) we have analyzed the source code of the

FB SDK to understand the interaction between our

app and FB client inside the smartphone, and (ii) we

have used the Fiddler proxy tool

to carefully inspect

the HTTP(S) trafﬁc between the FB client and the

FB server.

Registration Phase. To use the FB login solution

we had to register with FB. In this phase, we have en-

tered the app package name and the certiﬁcate ﬁnger-

print (called, key hash ) of our app (C). The key hash

is a digest (SHA1) of the ﬁle CERT.RSA, that con-

tains the public key of the developer, the signature

of the app package (APK) obtained with the private

We also analyzed the FB ﬂow with more recent versions

(Android 5.1.1, FB Android SDK 4.1.0 and FB APK

44.0.0.26.142), even if some parameters of the API calls

are different, the overall ﬂow matches.

Available at http://ﬁddler2.com/.

key of the developer, and other information about the

certiﬁcate. After the registration phase, an identiﬁer

(C id ) is associated with our native app.

Before the step description, we deﬁne the Android

components used by the FB solution. To manage

the inter-communication between two apps, FB use

explicit intents and the startActivityForResult

method. An intent is an inter-process communica-

tion mechanism and is called: (i) explicit, when the

sender speciﬁes the name of the receiver, and (ii)

implicit, whereby the sender only speciﬁes the re-

quired task without specifying any receiver. The

startActivityForResult method allows an app to

display an Activity (basically a user interface) of an-

other app and get a result back.

SSO Phase. Figure 5 depicts the most important

steps, abstracting away the steps that are irrelevant

for the authentication process. In Step 1 the user

opens C and clicks the “Login with Facebook” but-

ton to authenticate in C. This triggers the invoca-

tion (Step 2) of an Activity from FB client using the

method startActivityForResult. C is put on wait

for the Activity to return a result. In Step 3, FB client

presents to the user an interface for prompting her cre-

dentials. The user enters her credentials and activates

a “Log in” button. In Step 4, FB client interacts with

the FB server in order to authenticate the user. Note

For more details see the Android documentation,

available at http://developer.android.com/reference/an

droid/app/Activity.html#startActivityForResult(android.

content.Intent,int).

Security of Mobile Single Sign-On: A Rational Reconstruction of Facebook Login Solution

151

that, the HTTPS request contains the user credentials

and a parameter, sig, which is the hash of the param-

eters on the request calculated using a speciﬁc value

stored in the FB client app. As a response to the au-

thentication request (Step 5), FB client gets the user

information, among which there is the user’s identi-

ﬁer (u id ), and an access token (token FB). token FB

is used by the FB client to obtain conﬁguration and

user information. Note that, token FB has no expira-

tion date, but can be invalidated by the user either by

changing password or logging-out in the device.

Remark 1. We can observe that Steps 3-5 of Figure 5

correspond to the steps of Figure 2 with the User,

FB client and FB server playing the role of OAuth

RO, C and AS respectively. As the RO password cre-

dential, the FB implementation eliminates the need

for storing the user credentials for future use, by ex-

changing the credentials with a long-lived access to-

ken (token FB).

In Step 6, using the Android method

getPackageInfo(client packageName, Package

Manager.GET SIGNATURES) FB client extracts

the information about the certiﬁcate ﬁngerprint

(key hash) included in the package of C, and in

Step 7, it sends a token request for C to FB server,

including C id, key hash and u id. First, FB server

checks whether the provided key hash matches

the one previously provided by the developer for

the given C id in the registration phase. If there

is no match then the ﬂow is interrupted with an

error, otherwise FB server checks whether the user

authorized C. If C was not authorized by the user,

the response (Step 8) contains a consent form. The

consent form asks the user to grant or deny C to read

the proﬁle information. Otherwise, if C was already

authorized by the user, the consent phase is skipped.

If the user agrees, the response (Step 9) contains the

access token for C (token C). In Step 10, FB client

returns control to C and provides token C as result of

the invoked Activity (see Step 2).

Remark 2. At this point, it is interesting to do an-

other comparison with the OAuth ﬂows. We have

that Steps 2 and 7-10 of Figure 5 can be compared

with Steps 1-3 and 6-7 of Figure 3 with the User, C,

FB client, and FB server playing the role of OAuth

RO, C, UA, and AS, respectively. We can observe that

in the FB solution the WHCR entity is missing. The

WHCR is the server side of C and is needed to give

to the UA the instructions to interpret the fragment

values (e.g., access token value) returned in Step 3

and pass them to C. This procedure has been designed

to manage the same-origin policy when Cs are web

browser applications. Many native apps do not have

a corresponding server, so in the FB native solution,

the redirection URI is the same for every native app

and has the value fbconnect://success. Indeed, it

is the FB client that received the script and read the

access token out of the URI. In addition, we observe

that Step 8 of Figure 5 corresponds to Step 2 of Fig-

ure 3 without the user login (the user identity is passed

using the u id parameter).

Finally, C sends a request (Step 11) to the FB server

including token C to obtain the user information. C

obtains the user information from FB and this proves

that C is under control of the corresponding user.

By analyzing the FB solution, we have noticed

that it is the combination of two OAuth ﬂows (Re-

source Owner password credential and Implicit), and

the FB client app has two purposes: (i) it permits FB

to authenticate C, and (ii) manages the SSO process

(user authentication and access token release). In ad-

dition, we observe that the FB solution satisﬁes the re-

quirements expected for a SSO solution: (i) a user has

to register only with the FB server and can use her FB

credentials with different native apps (Cs). This sat-

isﬁes requirements (R1); (ii) using FB client allows

user to enter her FB credentials just once, and the

app will store the authenticated session. Every time

a native app requires to login with the FB server, the

FB client will employ the stored session without ask-

ing the user for credentials again. This satisﬁes (R2).

3.3 Security Assumptions and Threat

Model

In order to perform a security analysis of the Face-

book solution, we need to identify security assump-

tions and threat model of a native SSO ﬂow. We de-

cide to express these assumptions for a generalized

SSO solution, where the entities involved are: the hu-

man participant (User), the server that authenticates

the user (IdP server), the native app that manages au-

thentication and token exchange (IdP client), and the

native app that uses the authentication assertions of

the IdP (C).

3.3.1 Assumptions

The exchange of authentication assertions among the

different entities are regulated by the following as-

sumptions:

(A1) IdP server is trusted by C on identity asser-

tions;

(A2) users download and install the proper

IdP client apps (i.e., IdP client is authentic and

SECRYPT 2016 - International Conference on Security and Cryptography

152

trusted);

(A3) messages between C/IdP client and IdP server

are exchanged over HTTPS channels.

If (A1) does not hold, then IdP server could be mali-

cious and C may obtain a fake identity assertion and

credentials can be stolen by malicious IdP client apps.

Finally, (A3) is needed to avoid that a malicious at-

tacker can sniff or change information during the net-

work communication.

Besides the usual HTTP(S) channels used to inter-

act with the remote entities, it is necessary to consider

the communication mechanisms used inside the mo-

bile device. In FB native SSO solution, as we have

described in Section 3.2, the communication between

two apps is performed using explicit intents and the

startActivityForResult method. Note that, as-

suming

(A4) the integrity of the Android OS,

the Android method, used in FB, cannot be attacked.

Indeed, A4 ensures: (i) app isolation, i.e. the data of

an app cannot be visible to other apps on the device,

(ii) protection against database corruption, i.e. an app

cannot modify ﬁles of another app, and (iii) secure

communication mechanisms, i.e., for example, an app

cannot intercept or modify the value released as re-

sult of an Activity invoked by another app using the

startActivityForResult method. In addition, as

FB, we assume:

(A5) the use of explicit intents.

In this way, the system is not vulnerable to a number

of known attacks described in (Chin et al., 2011).

Note that, assumptions (A4) and (A5) ensure: (i)

the conﬁdentiality of the messages sent from C to

IdP client, and (ii) the authenticity of the messages

received by C from IdP client.

3.3.2 Threat Model

Based on the assumptions deﬁned above, an attacker

may be:

Malicious App: an application installed on the users

device that tries to violate the SSO ﬂow. In par-

ticular, if the Malicious App plays the role of C

in the SSO ﬂow, we call it Malicious C. Compare

to a general Malicious App, a Malicious C can

also access security relevant parameters used in

the SSO ﬂow.

Malicious User: a human person that plays the role

of User in the SSO ﬂow and can extract informa-

tion from her smartphone (e.g., having root per-

missions) or use tools to reverse engineering ap-

plications.

Clearly, an attacker can be also a combination of these

attacker types.

3.4 Security Analysis of Facebook

Native SSO

Given that the FB native SSO solution is based on

OAuth, to perform our security analysis we took into

account the security considerations reported in the

OAuth speciﬁcation (IETF, 2012a, §10), where for

each possible attack the respective countermeasures

are described. Our goal was to check whether the FB

native SSO solution described in Section 3.2—under

the security assumptions and thread models consid-

ered in Section 3.3—is vulnerable to the attacks re-

ported in (IETF, 2012a). To test whether the at-

tacks could be reproduced in the actual deployment,

we used the implementation described in (Facebook,

2015), which requires the use of FB Android SDK,

and playing the role of a malicious app. As a result of

these tests, we have discovered that, even if some im-

plementation choices (e.g., the use of explicit intent

described in Section 3.3.1) protect the FB native SSO

solution from some known attacks, it anyway suffers

from:

• Phishing: malicious apps can create a fake login

form and steal user credentials.

This attack can be easily performed (as pointed

out in (Khorana, nd)). In this case App

, when

the user clicks on the “Login with Facebook” but-

ton, shows a fake login form, equals to the one

shown by the FB client, and it is thus able to steal

the victim’s credentials. This is possible as the FB

solution allows us to start the authentication pro-

cess from the C apps. Note that, even assuming

that the user is a security expert, she has no way

to discover the ongoing attack as the login form

shown by App

can be identical to the login form

shown in the FB login ﬂow.

• User Impersonation: as a consequence of this at-

tack, an attacker can login in a benign C as another

user.

To reproduce this vulnerability, we have per-

formed the attack described in Figure 6, where we

play the role of an attacker and Alice is the victim:

– Session 1: App

(playing the role of a C),

which is installed in the Alice’s smartphone,

obtained a valid token linked to Alice’s iden-

tity.

– Session 2: we (playing the role of a user) ob-

tained a new token for a benign C using our

smartphone. Then, before the execution of Step

11, we changed the token linked to our identity

Security of Mobile Single Sign-On: A Rational Reconstruction of Facebook Login Solution

153

Session 1

FB_client

FB_server

Alice

1. click on

3. input

credentials

10.

token_C of Alice

11. token_C of Alice

12. user info of Alice

StartActivityForResult

2. login

request

9. token_C of Alice

6. read

key_hash

steps 4-5, 7-8

Session 2

FB_client

Attacker

10.

token_C of Attacker

11. token_C of Alice

12. user info of Alice

StartActivityForResult

2. login

request

9. token_C of Attacker

6. read

key_hash

1. click on

FB_server

3. input

credentials

steps 4-5, 7-8

Figure 6: User Impersonation Attack in the Facebook Native SSO Solution.

with the Alice’s token. This is possible as we

(the attacker) are the owner of the smartphone

where the SSO ﬂow is running.

To mitigate the user impersonation, a C devel-

oper has to check that the token (or in general

the identity assertion) used to retrieve the user in-

formation has been granted to his/her application.

In the FB native SSO solution, the default token

used is a bearer token, thus it does not contain

any information about the authentication process,

the only way to validate the token is to request

the token information to the FB

server. The prob-

lem is that, as before, the attacker can manipu-

late this request. For certain types of apps (e.g.,

games), FB suggests to set as response token pa-

rameter in Step 7 of FB native SSO ﬂow the value

signed request (Facebook, 2016) (we do not write

this parameter in Figure 5 as it is not related to the

security analysis). Using this value, a C app can

obtain extra information about users, such as the

age and the origin country. In this way, before

the real use, the C can personalize the app or deny

the access (e.g., for game that requires a minimum

age). This extra info is returned in a Json Web To-

ken (JWT - (IETF, 2015)). We want to observe

that, even using this token, the attack is valid. This

is because the information about the audience of

the token (the client identiﬁer) is missing. So, a

developer can check that a token was sent by FB

and extract the user info, but cannot check if the

token was released for itself.

• Client Impersonation: a malicious C can imper-

sonate another C to the IdP server obtaining user

identities and access protected resources.

As previously explained in Section 3.2, the FB so-

lution is a combination of two OAuth ﬂows, thus

we have to consider two different clients:

– the mobile app (C) in the Implicit ﬂow, and

– the FB client plays the role of C in the RO pass-

word credential ﬂow.

In the ﬁrst case, we have observed that, perform-

ing the veriﬁcation of the key hash value (after

Step 7 in Figure 5), the FB solution mitigates the

client impersonation attack. Indeed, a malicious

C cannot have the same certiﬁcate of a benign C,

as the certiﬁcate depends on the private key of the

C developer.

In the second case (when FB client plays the role

of C), we discovered that the client imperson-

ation attack is exploitable. This is possible as

the knowledge of the user’s credentials is the only

factor used by the FB server to authenticate the

FB client. Thus, being the FB solution vulnera-

ble to phishing attack, a malicious C, after obtain-

ing the user’s credentials, can also impersonate

the FB client sending the same message of Step

4 in Figure 5. To test this, we used the Advanced

Rest Client,

allowing us to test custom HTTP re-

quests. In detail, we have simulated the call of

Step 4 of Figure 5 and, entering the user creden-

tials, we were able to obtain a valid token. Note

that, to perform this call, an attacker has to gen-

erate the sig parameter. In our test, we was able

to discover the method used to generate the hash

value by reverse-engineering the FB client app. It

is also important to notice that the token obtained

was targeted for the FB client, and so it has no

Available at https://chrome.google.com/webstore/detail/

advanced-rest-client/hgmloofddffdnphfgcellkdfbfbjeloo.

SECRYPT 2016 - International Conference on Security and Cryptography

154

expiration date and it allows one to access all the

user data.

4 SECURING THE FACEBOOK

SSO SOLUTION

Starting from the FB native SSO solution and taking

advantage of our security analysis, in this section we

propose a native SSO solution capable of mitigating

the vulnerabilities described in Section 3.4. This so-

lution generalizes the one proposed by FB, in such a

way that it can be used as a reference model by any

IdP, willing to provide its own SSO solution.

Our generalized SSO solution involves the entities

described in Section 3.3. The idea is that IdP client

enables the execution of the processes of (delegated)

authorization and (user) authentication, needed by C

to access the user proﬁle, by exchanging messages

with the IdP server. After downloading IdP client,

both a registration phase and an activation phase are

required before the actual execution of the native SSO

ﬂow. Below, we ﬁrst hint the two preliminary phases

and then describe the routine use of IdP client, called

SSO process.

Registration Phase. The goal is to enable C to in-

teract with IdP client to obtain the user proﬁle. This

registration phase is performed by the C developers

and being in line with the FB registration phase we

have detailed it in Appendix.

Activation Phase. The goal is to enable the

IdP client to securely interact with the IdP server and

store a user session token. Using a web portal made

available by the IdP server, the User generates an ac-

tivation code. Then, using her mobile device, the User

digits it into IdP client.

SSO Phase. The actual execution of the native SSO

ﬂow is shown in Figure 7 and, being similar with the

FB native SSO solution, is described in Appendix.

The two differences are:

• the generation of the sig parameter in Step 5

of Figure 7. Instead of using a value that is

the same for IdP client installation, we use the

activation code value (different for each user);

• the token type of the token C in Step 6 of Fig-

ure 7. Instead of using bearer tokens (the default

tokens of OAuth), we use digitally signed tokens

that contain claims about the user authentication

phase (e.g., a JWT). We required at least three

claims: an issuer identiﬁer (IdP id), a user identi-

ﬁer (u id), the audience that the token is intended

for (C id).

Thus, compared to the FB solution, we propose

the following changes:

• we require the described activation phase that re-

places Steps 3-5 of FB native SSO solution (Fig-

ure 5);

• we use the activation code to obtain the sig pa-

rameter;

• token C contains claims about the user authenti-

cation phase and is digitally signed.

Note that, these changes are enough to mitigate

the security vulnerabilities reported in Section 3.4, in

detail:

• Phishing: is mitigated by the fact that users do

not have to insert their IdP credentials on mobile

native apps. Obviously, our solution cannot avoid

the phishing if a malicious app shows a fake login

form and the user decides to enter her IdP creden-

tials. However, note that, even if an organization

is able to develop a properly secured system, the

phishing attack can be performed exploiting users

lack of attention. Thus, at the basis of the phish-

ing mitigation, there is the user education (e.g.,

do not download email attachments sent by peo-

ple you do not know). In our solution, we will

train our users to not enter their IdP credentials

inside mobile apps. In this way, while in the FB

solution the user (even a security expert) cannot

detect the ongoing attack (a malicious C can cre-

ate the same login form of FB), in our model if

a malicious app asks to insert the IdP credentials,

the user can detect the ongoing attack;

• User Impersonation: to avoid the user imperson-

ation attack, we have decided to adopt the token

type introduced by the OpenID Connect solution.

In this way, C does not need to ask for user infor-

mation from the IdP server and can directly check

on the phone if the token was released to itself;

• Client (IdP client) Impersonation: is mitigated

as the IdP client app is authenticated by the

IdP server using the sig parameter generating

with an activation code that is different for each

user. By doing so, even if in principle, the

activation code of the IdP client app can be ac-

cessed by the owner of the phone, she cannot

We want to underline again, that as OAuth, also OpenID

Connect is a browser-based solution and, thus, we cannot

use it directly as it provides only a partial support for the

mobile native SSO scenario.

Security of Mobile Single Sign-On: A Rational Reconstruction of Facebook Login Solution

155

1. click on

IdP_server

User

5. token request,

C_id&key_hash&sig

4. user consent

7. token_C(IdP_id,u_id,C_id)

StartActivityForResult

2. login

request,

C_id

6. token_C(IdP_id,u_id,C_id)

3. read

key_hash

IdP_client

Figure 7: Our Native SSO Solution.

reuse it for obtaining token related to other users

apart from herself.

We want to stress that the activation phase will be

performed only the ﬁrst time the user interacts with

the IdP client app. Thus, after the download and the

activation of the IdP client app, users can directly

open the different C apps as usual. A scenario to

be covered is the following: what would happen if

a user starts C without having already activated the

IdP client? A possible solution is described here: if

the IdP client is installed on the phone, C will perform

the login request to the IdP client, and the IdP client

will show an alert saying that the user needs to com-

plete the activation with the IdP client app. Other-

wise, C will show an error requiring the IdP client

installation.

5 RELATED WORK

A ﬁrst attempt of native SSO standardization is car-

ried out by the OpenID Foundation with the working

group NAPPS (Native Applications) (OIDF, 2014b).

Our model has some similarities with the NAPPS

project, such as the use of digitally signed token, and

the idea of introducing a new entity into the mobile

phone that manages: (i) token exchanges, and (ii) user

authentication and authorization processes. However

being only a draft speciﬁcation, NAPPS lacks a secu-

rity analysis and many technical details. The NAPPS

group is waiting to deliver a complete speciﬁcation

of its solution, as the mobile OSs (both iOS and An-

droid) have been developing new features for support-

ing the native SSO (see (Madsen, 2015b; Madsen,

2015a)). They will introduce a new mechanism to

implement browser-based protocol, which is a middle

ground between the two browser solutions currently

used (embedded and external browser). We will per-

form a further analysis as soon as details are available.

There are many studies in the literature, such as

(Armando et al., 2008; Bansal et al., 2012; Sun and

Beznosov, 2012; Wang et al., 2012; Zhou and Evans,

2014), which focus on the analysis of the different

SSO implementations and the description of common

vulnerabilities and attacks caused by incorrect imple-

mentation assumptions. These work, however, per-

formed the analysis of the SSO for web applications,

while the focus of our study is on native apps.

An in-depth analysis of OAuth in the mobile

environment—underlining possible security prob-

lems and vulnerabilities—is performed by (Chen

et al., 2014) and (Shehab and Mohsen, 2014). In

(Chen et al., 2014), the two main problems addressed

are: (i) the use of OAuth as an authentication proto-

col, and (ii) the lack of a mechanism to securely per-

form redirection in mobile platforms. The difference

between (Chen et al., 2014) and our work is the goal

that we want to achieve. (Chen et al., 2014) aims to be

a warning about the need for a clearer OAuth guide-

line for mobile app developers, whereas we want to

propose a reference model for native SSO. In the con-

text of authorization, (Shehab and Mohsen, 2014) has

a similar goal. They propose a new framework for

securing the OAuth ﬂow in smartphones. This frame-

work requires the use of an embedded browser man-

aged by a trusted app. In this way it does not require

the download of an app for every different IdP and

SECRYPT 2016 - International Conference on Security and Cryptography

156

provides the required separation between C and the

UA. However, the level of detail provided is not suf-

ﬁcient to clarify, for example, how this solution pre-

vents phishing and client impersonation attacks (de-

scribed in Section 3.3).

About the Facebook solution for native apps, we

based our study on the examples of attacks found in

(Khorana, nd; Homakov, 2013; Goldshlager, 2013;

Yao, 2010; Wulf, 2011).

6 CONCLUSIONS

The lack of security guidelines for mobile native SSO

solutions has driven us to perform a detailed analysis

of Facebook login current implementation. Starting

from this analysis, we have contributed in this way:

(i) we have extracted a rational reconstruction of the

Facebook native SSO ﬂow, (ii) we have performed

a security analysis clarifying which are the security

and trust assumptions and threat model for a native

SSO scenario, and (iii) we have generalized the Face-

book solution in a SSO model capable of mitigating

the identiﬁed vulnerabilities.

As future work, we plan to (i) provide an imple-

mentation of our proposed solution, (ii) use a formal

technique to provide a formal analysis of our solution,

and (iii) reﬁne our solution taking into account the au-

thorization aspect.

ACKNOWLEDGEMENTS

This work has partially been supported by the Activity

no. 16298, “Federated Identity Management System”

(FIDES), funded by the EIT Digital.

REFERENCES

Armando, A., Carbone, R., Compagna, L., Cu

ellar, J., and

Tobarra, L. (2008). Formal Analysis of SAML 2.0

Web Browser Single Sign-On: Breaking the SAML-

based Single Sign-On for Google Apps. In Proceed-

ings of the 6th ACM workshop on Formal methods in

security engineering (FMSE ’08), pages 1–10.

Bansal, C., Bhargavan, K., and Maffeis, S. (2012). Dis-

covering Concrete Attacks on Website Authorization

by Formal Analysis. In 25th IEEE Computer Security

Foundations Symposium (CSF’12), pages 247–262.

Boyd, R. (2012). Getting Started with OAuth 2.0. http://it-

ebooks.info/read/664/.

Chen, E., Pei, Y., Chen, S., Tian, Y., Kotcher, R., and Tague,

P. (2014). OAuth Demystiﬁed for Mobile Application

Developers. In Proceedings of the ACM Conference

on Computer and Communications Security (CCS).

Chin, E., Felt, A. P., Greenwood, K., and Wagner, D.

(2011). Analyzing Inter-application Communication

in Android. In Proceedings of the 9th International

Conference on Mobile Systems, Applications, and Ser-

vices, pages 239–252.

Facebook (2015). Getting Started with the Facebook

SDK for Android. https://developers facebook.

com/docs/android/getting-started/facebook-sdk-for-

android/.

Facebook (2016). Signed Requests. https://developers.

facebook.com/docs/reference/login/signed-request.

Goldshlager, N. (2013). How I hacked any Facebook Ac-

count...again! http://www.nirgoldshlager.com/2013/

03/how-i-hacked-any-facebook-accountagain.html.

Homakov, E. (2013). How we hacked face-

book with OAuth2 and Chrome bugs.

http://homakov.blogspot.no/2013/02/hacking-face

book-with-oauth2-and-chrome.html.

IETF (2012a). The OAuth 2.0 Authorization Framework.

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

IETF (2012b). The OAuth 2.0 Authorization Frame-

work: Bearer Token Usage. https://tools.ietf.org/html/

rfc6750.

IETF (2015). JSON Web Token (JWT).

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

Khorana, T. (n.d.). Fake Facebook Phishing Attack.

https://sites.google.com/site/mobilesecuritylabware/9-

mobile-phishing/post-lab-activities/lab-1-fake-

facebook-phishing-attack.

Madsen, P. (2015a). Mobile OS Develop-

ments & Native Application Authentication.

https://www.pingidentity.com/en/blog/2015/06/19/

mobile

os developments native application authentica

tion.html.

Madsen, P. (2015b). NAPPS has left the

building (but is still on the front lawn).

https://www.pingidentity.com/en/blog/2015/07/22/

napps has left the building but is still on the front

lawn.html.

OASIS (2005). SAML V2.0 technical overview.

https://docs.oasis-open.org/security/saml/v2.0/saml-

core-2.0-os.pdf.

OIDF (2014a). OpenID Connect Core 1.0. http://openid.

net/specs/openid-connect-core-1 0.html.

OIDF (2014b). OpenID Connect Native Application To-

ken Agent Core 1.0. http://openid.bitbucket.org/draft-

native-application-agent-core-01.html.

Shehab, M. and Mohsen, F. (2014). Towards Enhancing the

Security of OAuth Implementations in Smart Phones.

In IEEE International Conference on Mobile Services

(MS), pages 39–46.

Sun, S. and Beznosov, K. (2012). The Devil is in the

(Implementation) Details: An Empirical Analysis of

OAuth SSO Systems. In Proceedings of the ACM

Conference on Computer and Communications Secu-

rity (CCS’12).

Wang, R., Chen, S., and Wang, X. (2012). Signing Me

onto Your Accounts through Facebook and Google: A

Security of Mobile Single Sign-On: A Rational Reconstruction of Facebook Login Solution

157

Trafﬁc-Guided Security Study of Commercially De-

ployed Single-Sign-On Web Services. In IEEE Sym-

posium on Security and Privacy (SP), pages 365–379.

Wang, R., Zhou, Y., Chen, S., Qadeer, S., Evans, D., and

Gurevich, Y. (2013). Explicating SDKs: Uncovering

Assumptions Underlying Secure Authentication and

Authorization. In Proceedings of the 22Nd USENIX

Conference on Security (SEC’13), pages 399–414.

Wulf, A. (2011). Stealing Passwords is Easy

in Native Mobile Apps Despite OAuth.

http://welcome.totheinter.net/2011/01/12/.

Yao, Y. (2010). A serious OAuth security

hole in Facebook SDK. http://security-n-

tech.blogspot.it/2010/11/serious-oauth-security-

hole-in-facebook.html.

Zhou, Y. and Evans, D. (2014). SSOScan: Automated

Testing of Web Applications for Single Sign-On Vul-

nerabilities. In 23rd USENIX Security Symposium

(USENIX Security 14), pages 495–510.

APPENDIX

For further information, we describe below the entire

ﬂow of our native SSO solution.

Registration Phase. We require a registration

phase similar to the one of FB, where C developer has

to enter the certiﬁcate ﬁngerprint of C (key hash) and

obtains a C identiﬁer (C id). This is to avoid the client

impersonation threat described in Section 3.3. In ad-

dition, in this phase, C and IdP

server have to agree

on a signature algorithm and exchange the required

public key.

Activation Phase. Using a web portal made avail-

able by the IdP server, the User generates an activa-

tion code. Then, using her mobile device, the User

digits it into IdP client.

SSO Phase. The SSO ﬂow, shown in Figure 7, is

composed by the following steps: in Step 1, the

user opens C and clicks the login button. When

a user clicks on the login button an Activity from

IdP client using an explicit intent and the method

startActivityForResult is invoked (Step 2). C

is put on wait for the Activity to return a result.

In Step 3, IdP client read the certiﬁcate ﬁngerprint

(key hash) of C, and in Step 4, presents a form that

asks the user whether to authorize C to access her dig-

ital identity. In Step 5, IdP client sends a request to

IdP server to get a fresh access token for C. The re-

quest contains C id, key hash and the sig parameter (a

hash value obtained using the activation code value).

IdP server checks whether the provided key hash

matches the one previously provided in the registra-

tion phase for the given C id. If there is a mismatch

then the ﬂow is interrupted returning an error, oth-

erwise the response (Step 6) contains a fresh token

(token C). In Step 7, IdP client returns control to C

and provides the token C as result of the invoked Ac-

tivity (see Step 2). C must validate the signature of the

token according to the algorithm and using the public

key speciﬁed in this registration phase. If the signa-

ture is valid, C has to perform two other steps: (i) ver-

ify if the issuer ﬁeld correspond to the IdP server, and

(ii) check if the value of the audience ﬁeld matches

with the C id. If the token is valid, C can extract the

user information. This proves that C is under control

of the corresponding user.

SECRYPT 2016 - International Conference on Security and Cryptography

158