See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/280873003

Analysing the Security of Google's implementation of OpenID Connect

Article · August 2015

Source: arXiv

CITATIONS READS

21 509

2 authors, including:

Chris J Mitchell
Royal Holloway, University of London
378 PUBLICATIONS 4,628 CITATIONS

SEE PROFILE

All content following this page was uploaded by Chris J Mitchell on 25 August 2015.

The user has requested enhancement of the downloaded file.

 Analysing the Security of Google’s implementation
of OpenID Connect
Wanpeng Li and Chris J Mitchell
Information Security Group,
arXiv:1508.01707v1 [cs.CR] 7 Aug 2015

Royal Holloway, University of London

TW20 0EX

August 11, 2015

Abstract
Many millions of users routinely use their Google accounts to log
in to relying party (RP) websites supporting the Google OpenID Con-
nect service. OpenID Connect, a newly standardised single-sign-on
protocol, builds an identity layer on top of the OAuth 2.0 protocol,
which has itself been widely adopted to support identity management
services. It adds identity management functionality to the OAuth 2.0
system and allows an RP to obtain assurances regarding the authen-
ticity of an end user. A number of authors have analysed the security
of the OAuth 2.0 protocol, but whether OpenID Connect is secure in
practice remains an open question. We report on a large-scale prac-
tical study of Google’s implementation of OpenID Connect, involving
forensic examination of 103 RP websites which support its use for sign-
in. Our study reveals serious vulnerabilities of a number of types, all
of which allow an attacker to log in to an RP website as a victim user.
Further examination suggests that these vulnerabilities are caused by
a combination of Google’s design of its OpenID Connect service and
RP developers making design decisions which sacrifice security for sim-
plicity of implementation. We also give practical recommendations for
both RPs and OPs to help improve the security of real world OpenID
Connect systems.

1 Introduction
In order to help alleviate the damage caused by identity-oriented attacks
and simplify the management of identities, a range of identity management
systems, such as OAuth 2.0, Shibboleth, CardSpace, OpenID, have been
put forward [20, 25, 36]. As a replacement for the well-established OpenID
[36] scheme, OpenID Connect 1.0 [37] builds an identity layer on top of
the OAuth 2.0 framework [25]. The OAuth 2.0 framework enables an RP
to obtain profile information about the end user, but does not provide any

1
means for the RP to obtain information about the authentication of the end
user. In OpenID Connect, in addition to obtaining profile information about
the end-user, RPs can obtain assurances about the end user’s identity from
an OpenID Provider (OP), which itself authenticates the user.
OpenID Connect involves interactions between four core parties:

1. the End User (U), who attempts to access on-line services protected
by the RP;
2. the User Agent (UA), typically a web browser, that is employed by
an end user to transmit requests to, and receive responses from, web
servers;
3. the OpenID Provider (OP), e.g. Google, which provides methods to
authenticate an end user and generates assertions regarding the au-
thentication event and the attributes of the end user;
4. the Relying Party (RP), e.g. Wikihow, which provides protected on-
line services and consumes the identity assertion generated by the IdP
in order to decide whether or not to grant access to the end user.

In summary, the end user employs a user agent to access resources pro-
vided and protected by the RP, which relies on the OP to provide authentic
information about the user.
Even though OpenID Connect was only finalised at the start of 2014,
there are already more than half a billion OpenID Connect-based user ac-
counts provided by Google [9], PayPal [6] and Microsoft [4]. This large
user base has led very large numbers of RPs to integrate their services with
OpenID Connect.
The security of OAuth 2.0, the foundation for OpenID Connect, has
been analysed using formal methods [32, 35, 39]. Research focusing on im-
plementations of OAuth 2.0 has also been conducted [22, 31, 41, 44, 47].
However, as a newly standardised protocol, it is not yet clear whether prac-
tical implementations of OpenID Connect properly follow the specification
[37]. Given the large scale use of the Google service, it is important to un-
derstand how secure deployments of OpenID Connect really are. In order to
help answer the question, the operation of all one thousand sites from the
GTMetrix Top 1000 Sites [11] providing services in English was examined.
Of these sites, 103 were found to support the use of the Google’s OpenID
Connect service, at the time of our survey (early 2015). All 103 of these
websites were then further examined for potential vulnerabilities, with the
results as reported in this paper. In our study, all the RPs and the Google
OP site were treated as black boxes, and the HTTP messages transmitted
between the RP and OP via the browser were carefully analysed to identify
possible vulnerabilities. For every identified vulnerability, we implemented
and tested an exploit to evaluate the possible attack surface.

2
 Our study reveals serious vulnerabilities of a number of types, which
either allow an attacker to log in to the RP website as the victim user or
enable the compromise of potentially sensitive user information. Google
has customised its implementation of OpenID Connect by combining SDKs,
web APIs and sample code, and as a result the OpenID Connect specifica-
tion only acts as a loose guideline to what RPs have actually implemented.
Further examination suggests that the identified vulnerabilities are mainly
caused by RP developers misunderstanding how to use the Google OpenID
Connect service, and by making design decisions which sacrifice security for
simplicity of implementation. Some of the attacks we have discovered use
cross-site scripting (XSS) [34, 43, 45, 30] and cross site request forgeries
(CSRFs) [17, 23, 29, 33, 46], well-established and widely exploited attack
techniques.
OpenID Connect is being used to protect millions of user accounts, as
well as sensitive user information stored at both RPs and the Google OP
server. Moreover, as of April 20th 2015, Google shut down its OpenID
2.0 [8] service; as a result a huge number of RPs have had to upgrade
their Google sign-in service to use OpenID Connect. It is therefore vitally
important that the issues we have identified are addressed urgently, and that
Google considers issuing updated advice to all RPs using its service. In this
connection we have notified all the RPs in whose OpenID Connect service
we have identified serious vulnerabilities, as well as Google itself.
The remainder of the paper is organised as follows. In Section 2 we
give an overview of OpenID Connect. We describe our adversary model in
section 3. Section 4 describes the experiments we performed to evaluate the
security of Google’s implementation of OpenID Connect. Possible reasons
for the identified vulnerabilities are discussed in section 5. In section 6 we
give proposed mitigations for these vulnerabilities, we review related work
in section 7, and section 8 concludes the paper.

2 OpenID Connect
2.1 Introduction
OAuth 2.0 [25] enables an end user to grant an online service controlled
access to his or her personal details (e.g. email address, birth date, pictures)
held by a third party, without revealing his or her password for this third
party. Without the help of a system like OAuth 2.0, relying parties (e.g.
Wikihow) would need to ask the user to provide his or her password in order
to access user information stored at a third party (e.g. Google), which is a
less than ideal solution.
As already noted, OpenID Connect 1.0 [37] is built as an identity layer
on top of the OAuth 2.0 protocol. The functionality that it adds enables RPs
to verify the identity of an end user by relying on an authentication process

3
performed by an OpenID Provider (OP), i.e. it adds identity management
functionality to the OAuth 2.0 system.

2.2 OpenID Connect Tokens

In order to enable an RP to verify the identity of an end user, OpenID
Connect adds a new type of token to OAuth 2.0, namely the id token. This
complements the access token and code, which are already part of OAuth
2.0. These three types of token are all issued by an OP, and have the
following functions.

• A code is an opaque value which is bound to an identifier and a URL of

the RP. Its main purpose in OpenID Connect is as a means of giving
an RP authorisation to retrieve tokens from the OP. In order to help
minimise threats arising from its possible exposure, it has a limited
validity period and is typically set to expire shortly after issue to the
RP [25].

• An access token contains credentials used to authorise access to pro-

tected resources stored at a third party (e.g. the OP). Its value is an
opaque string representing an authorization issued to the RP. It en-
codes the right for the RP to access data held by a specified thrid
party with a specific scope and duration, granted by the end user and
enforced by the RP and the OP.

• An id token contains claims about the authentication of an end user

by an OP together with any other claims requested by the RP. Claims
that can be inserted into such a token include: the identity of the OP
that issued it, the user’s unique identifier at this OP, the identity of
the intended recipient, the time at which it was issued, and its expiry
time. It takes the form of a JSON Web Token [28] and is digitally
signed by the OP.

Both an access token [7] and an id token [13] can be verified by making
a call to the web API of the issuing OP.

2.3 Authentication Flows

OpenID Connect builds on user agent HTTP redirections. We suppose that
an end user wishes to access services protected by the RP, which consumes
tokens generated by the OP. The RP generates an authorization request on
behalf of the end user and sends it to the OP via the UA, which is typically
a web browser. The OP provides ways to authenticate the end user, asks
the end user to grant permission for the RP to access the user attributes,
and generates an authorization response which includes tokens of two types:
access tokens and id tokens, where the latter contain claims about a user

4
authentication event. After receiving an access token, the RP can use it to
access end user’s attributes using the API provided by the OP, and after
receiving an id token the RP is informed about the authentication of the
user, as summarised in Fig. 2.1.

Figure 2.1: OpenID Connect Protocol Overview

Google’s implementation of OpenID Connect [37] supports four types of

authentication flow [9], i.e. ways in which the system can operate, namely
Authorization Code Flow, Hybrid Server-side Flow (also knows as Hybrid
Flow ) [10], Client-side Flow (also known as Implicit Flow ), and Pure Server-
side Flow. However, as the Pure Server-side Flow is rarely used and Google
states that this flow is not recommended, we only give detailed descriptions
of the first three flows.
The RP must register with the OP before it can use Google OpenID
Connect. During registration, the OP gathers security-critical information
about the RP, including the RP’s redirect URI or origin. The redirect URI
is used in the Authorization Code Flow , and is the URI to which the user
agent is redirected after step 5 (see step 5 of section 2.3.3). The origin is
used in the Hybrid Server-side Flow and Client-side Flow , and is a pointer
to the domain name of the RP. The OP issues the RP with a unique identifier
(client id) and a secret (client secret) which it uses to authenticate the RP
when using the Authorization Code Flow or Hybrid Server-side Flow .

5
2.3.1 Hybrid Server-side Flow
Google’s OpenID Connect implementation uses postMessage [1, 5, 18, 40]
to enable cross domain communication between the RP and Google’s OP.
Normally, scripts on different pages are only allowed to access each other
if the web pages that caused them to execute are at locations sharing the
same protocol, port number and host. The postMessage method lifts this
restriction by providing a way to securely pass messages across domains.
Further information on the operation of postMessage can be found, for
example, in Son and Shmatikov [40]. In the Hybrid Server-side Flow and
Client-side Flow , an RP Client is running on the UA and listening for the
postMessage event.
We now give a detailed description of the Hybrid Server-side Flow .

1. U → UA → RP: The user clicks the Google Sign-In button rendered on

the RP website, and this causes the UA to send an HTTP or HTTPS
request to the RP.

2. RP → UA → OP: The RP generates an OpenID Connect authorization

request and sends it to the OP via the UA. The authorization request
includes client id, an identifier the RP registered with the OP previ-
ously; response type=code token id token which requests that a code,
an access token and an id token be returned directly from Google;
redirect uri=postmessage, indicating that postMessage is being used;
state, an opaque value used by the RP Client to maintain state between
the request and the callback (step 5 below); origin, a URL without a
path appended; and scope, the scope of the requested permission.

3. OP → UA: If the user has already been authenticated by the OP

then this step and the next are skipped. If not, the OP returns a login
form which is used to collect user authentication information (e.g. user
account and password).

4. U → UA → OP: The user completes the login form and grants per-
mission for the RP to access the attributes stored by the OP.

5. OP → UA: After receiving the permission grant from the user, the
OP generates an HTML document which contains the authorization
response and sends it back to the UA. The authorization response
contains the code, access token and id token generated by the OP;
and state, the value sent in step 2.

6. UA → RP: The UA executes the JavaScript inside the HTML docu-

ment it received in the previous step. The JavaScript sends the au-
thorization response using postMessage to the RP Client which is
running on the UA and listening for the postMessage event. After

6
 the RP Client receives the authorization response it extracts the code
and sends it back to the RP.

7. RP → OP: The RP produces an access token request and sends it

to the OP token endpoint directly (i.e. not via the UA). The request
includes grant type=authorization code, indicating that the RP wants
to use the code to retrieve an access token from the OP; the code gen-
erated in step 5; redirect uri=postmessage, indicating that postMes-
sage has been used to get the code; and client secret, the secret shared
by the RP and OP.

8. OP → RP: The OP checks the code, client secret and redirect uri and,
if correct, responds to the RP with access token and id token, the
latter of which is the same as the id token sent in step 5.

9. RP → OP: The RP verifies the id token. If it is valid, the RP now

has evidence that the user has been authenticated. If necessary it can
also make a web API call to retrieve the user attributes from the OP
using the access token as evidence of its right to do so.

In Google’s implementation of Hybrid Server-side Flow , a code, an ac-

cess token and an id token are always returned by Google to the RP’s
JavaScript client running on the user’s browser. This means that these
tokens are potentially revealed to the user agent and any applications which
might be able to access the user agent.

2.3.2 Client-side Flow

The authorization request and response employed in the Client-side Flow are
similar to those used in the Hybrid Server-side Flow . The only difference
between the two flows is that in the Client-side Flow no code is submitted
back to the RP. The Client-side Flow operates as follows, where steps 1-5
are the same as steps 1-5 in section 2.3.1.

6. UA → RP: The UA executes the JavaScript inside the html document

it received in the previous step. The JavaScript sends the authorization
response using postMessage to the RP Client that is running on the
UA and listening for the postMessage event. After receiving the
authorization response, the RP Client extracts the access token and
id token. It then verifies the id token; if the id token is valid, the RP
now has evidence that the user has been authenticated. If necessary it
can also make a web API call to retrieve the user attributes from the
OP, using the access token as evidence of its right to do so.

7. UA → U: The RP Client running on the UA updates the displayed

web page based on the attributes it retrieved in the previous step.

7
2.3.3 Authorization Code Flow
One advantage of this flow is that no tokens are made available to the user
agent or to any malicious applications which might be able to access the
user agent. This is advantageous since if either of the tokens are obtained
by a malicious party they could be used to access sensitive user data and/or
successfully masquerade as the user. The OP must authenticate the RP
before it issues the pair of tokens, and hence use of the Authorization Code
Flow requires that an RP shares a secret with the OP. The flow involves the
OP returning an authorization code, typically a short-lived opaque string,
to the RP, which uses it to obtain the id token and access token directly
from the OP’s access token endpoint, i.e. not via the UA. The main steps
are as follows.

1. U → RP: The user clicks a login button on the RP website, as displayed

by the UA, which causes the UA to send an HTTP or HTTPS request
to the RP.

2. RP → UA → OP: The RP generates an OpenID Connect authorization

request and sends it to the OP via the UA. The authorization request
includes client id, a client identifier which the RP registered with the
OP previously; response type=code, indicating that the Authorization
Code Flow is being used; redirect uri, the URI to which the OP will
redirect the UA after access has been granted; state, an opaque value
used by the RP to maintain state between the request and the callback
(step 5 below); and scope, the scope of the requested permission.

3. OP → UA: If the user has already been authenticated by the OP then

this step and the next are skipped. If not, the OP returns a login form
which is used to collect user authentication information.

4. U → UA → OP: The user completes the login form and grants per-
mission for the RP to access the attributes stored by the OP.

5. OP → UA: After using the information provided in the login form to

authenticate the user, the OP generates an authorization response and
sends it back to the UA. The authorization response contains code,
the authorization code generated by the OP; and state, the value sent
in step 2.

6. UA → RP: The UA redirects the response received in Step 5 to the

RP.

7. RP → OP: The RP produces an access token request and sends it

to the OP token endpoint directly (i.e. not via the UA). The request
includes grant type=code, indicating the RP wants to use the code to

8
 retrieve an access token; the code sent in step 5; the redirect uri ; and
client secret, the secret shared by the RP and OP.

8. OP → RP: The OP checks the code, client secret and redirect uri and
if all are correct responds to the RP with an access token and id token.

9. RP → OP: The RP verifies the id token. If it is valid, the RP now has

evidence that the user has been authenticated. If necessary it can also
make a call to the web API offered by the OP, using the access token
for authorisation, in order to retrieve the desired user attributes.

3 Adversary Model
In our assessment of the security of Google’s implementation of OpenID
Connect, and of the implementations of specific RPs using the service, we
consider two possible scenarios for the capabilities of an adversary.

• A Web Attacker can share malicious links and/or post comments

which contain malicious content (e.g. stylesheets or images) on a be-
nign website; and/or exploit vulnerabilities in an RP website. The ma-
licious content forged by a web attack might trigger the web browser
to send HTTP/HTTPS requests to an RP and OP using either the
GET or POST methods, or execute JavaScript scripts crafted by the
attacker. For example, a web attacker could operate an RP website in
order to try to collect access tokens.

• A Passive Network Attacker has the ability to intercept unen-

crypted data sent between an RP and an end user browser (e.g. by
monitoring an open Wi-Fi network).

Conducting a security analysis of commercially deployed OpenID Con-

nect SSO systems requires a number of challenges to be addressed. These
include lack of access to detailed specifications for the SSO systems, undoc-
umented RP and OP source code, and the complexity of APIs and/or SDK
libraries in deployed SSO systems. The methodology we used is similar to
that employed by Wang et al. [44] and Sun and Beznosov [41], i.e. we anal-
ysed the browser relayed messages (BRMs). We treated the RPs and IdPs
as black boxes, and analysed the BRMs produced during authorization to
look for possible exploit points. Since we used a black-box approach, there
may very well be vulnerabilities, implementation flaws and attack vectors
which our study did not uncover.

9
4 A Security Study
To evaluate the security of OpenID Connect, we used Fiddler1 to capture
BRMs sent between RPs and the OP; we also developed a Python program
to parse the BRMs to simplify analysis and to avoid mistakes resulting from
manual inspections. All the experiments were performed using accounts set
up specially for the purpose; i.e. at no time was any user’s account accessed
without permission. Of the 103 RPs supporting Google OpenID Connect
that we examined, we found that 69 (67%) adopt the Authorization Code
Flow , 33 (32%) use the Hybrid Server-side Flow , and just 1 adopted the
Client-side Flow .

4.1 Studying the security of the Hybrid Server-side Flow

As described in section 2.3.1, Google’s OpenID Connect API uses postMes-
sage to deliver the authorization response from the OP to an RP. When the
RP Client running on the user’s browser receives the authorization response
from the OP, it extracts the code from the authorization response and then
submits the code back to the RP’s OpenID Connect sign-in endpoint.

4.1.1 Authentication by Google ID

As stated above, the RP’s JavaScript client running on the UA submits the
code it receives from the Google OP back to the RP’s Google sign-in endpoint
(see step 6 in section 2.3.1). The code plays a critical role in guaranteeing
the user identity to the RP, in that the RP is meant to use it to retrieve the
access token and id token from the Google OP. However, we observed that
18% of the RPs using the Hybrid Server-side Flow (i.e. 6 of the 33) submit
the user’s Google ID to the RP’s Google sign-in endpoint; of these six RPs,
two simply submit the user’s Google ID without appending a code, and one
submits the user’s Google ID with an access token. This led us to suspect
that such RPs might be basing their verification of user identity solely on
the Google ID, and not using the code as it is intended to be used. If this
were to be the case, then a web attacker which knows a user’s Google ID
could use it to log in to the user’s RP account. We tested this, and found
that as many as 9% of the RPs using the Hybrid Server-side Flow (i.e. 3 of
the 33) have this vulnerability.
It would appear that learning the Google ID for a victim user
can be relatively simple, as a user’s Google+ post URL reveals the
user’s Google ID. An attacker can use the Google+ search for peo-
ple function to find a victim user to attack, and can then visit
the chosen victim user’s Google+ page to learn the ID. For exam-
ple, https://plus.google.com/u/0/115722834054889887046/posts is
1
http://www.telerik.com/fiddler

10
the Google+ post URL for a Gmail account, for which the ID is
115722834054889887046.
We reported our findings to the three affected websites, and recommen-
dations were also provided to enable the RP developers to fix the problem
(see also 6.3).

4.1.2 Using the Wrong Token

An access token is a bearer token; this means that any party in possession
of an access token can use it to get access to the associated user attributes
stored by Google. This is the intended use of an access token; by contrast,
the id token is designed for use for providing assurances about user authen-
tication. However, in practice, some RPs use an access token as a means
of obtaining assurances about user authentication without verifying it (i.e.
making a web API call to the OP token information endpoint [7]). In such
a case, any party (e.g. another RP) that has obtained a user’s access token
can impersonate that user to the RP simply by submitting it. This is a
particular threat in the case of a malicious RP, which can routinely obtain
access tokens from the Google OP. In other words, any RP using Google
OpenID Connect has the ability to log in as a victim user to any RPs which
use an access token to authenticate the user without verifying it. Unfortu-
nately, we found that 58% of RPs using the Hybrid Server-side Flow (i.e.
19 out of 33) submit an access token back to their Google sign-in endpoint
(see step 6 in section 2.3.1) and 45% (i.e. 15 out of these 19) use the ac-
cess token to authenticate the user; of these 15 RPs, only two RPs verify
the access token before using it to retrieve user attributes. As a result,
39% of the RPs (i.e. 13 out of 33) that we examined are vulnerable to this
impersonation attack.
We tested the above attack using Burp Suite2 by submitting an ac-
cess token obtained from the 9GAG3 website to the target RP’s Google
sign-in endpoint. If the attack succeeds, we are able to log in to the target
RP as the victim user. As noted above, as many as 39% of the RPs using
the Hybrid Server-side Flow are vulnerable to this attack. Some of the vul-
nerable RPs (i.e. 3 out of 13) require additional evidence of the user to be
submitted with the access token, in the form of the Google ID or the user’s
email address. However, an attacker that has an access token can very eas-
ily use it to obtain the user’s Google ID and/or email address from Google,
and so such additional steps do not prevent the impersonation attack.
2
http://portswigger.net/burp/
3
http://9gag.com

11
4.1.3 Intercepting an access token
As stated above, 58% of RPs using the Hybrid Server-side Flow require the
submission of an access token back to their Google sign-in endpoint (see
step 6 in section 2.3.1). If the RP Client running on the UA sends an
access token back to its Google sign-in endpoint without SSL protection, a
passive network attacker is able to intercept it (see section 3). According
to the OAuth 2.0 specification [27], an access token should never be sent
unencrypted between the user browser and the RP. However, we found that
12% of RPs using the Hybrid Server-side Flow (i.e. 4 out of 33) send the
access token unprotected. A sniffer written in Python was implemented to
test this.
We also observed that one additional site, namely TheFreeDictionary4
does use SSL to protect the transfer of the code to its Google sign-in end-
point. However, the access token is subsequently stored in a cookie, and
when the cookie is sent from the browser back to TheFreeDictionary the
link is not SSL-protected. That is, the access token is observable by a pas-
sive eavesdropper.

4.1.4 Privacy Issues

When a user chooses to use OpenID Connect to log in to an RP website,
the user attributes (e.g. email address, name) that the RP retrieves from the
OP should never be revealed to parties other than the RP. SSL connections
should be established to protect user information transmitted between the
browser and the RP or OP.
However, as explored in greater detail below, user information leakage
might happen if:
• the RP Client running on the user’s browser sends user information,
the id token or the access token back to its Google sign-in endpoint
without SSL protection (see step 6 in section 2.3.1);

• the RP Google sign-in endpoint sends the user information directly to

the user’s browser without SSL protection; or

• the RP uses SSL to protect the link to the Google sign-in endpoint,
but changes to http when it sends the user’s information back to the
user’s browser.
As described in Section 4.1.3, a passive eavesdropper can intercept the
access token for 12% of the RPs that use the Hybrid Server-side Flow (i.e.
4 out of 33), and can then use it to retrieve potentially sensitive user in-
formation, notably including the Google ID and email address. As stated
in section 2.2, the id token is a JSON web token, in which the user email
4
http://www.thefreedictionary.com

12
address and Google ID are encoded in cleartext using Base64; as a result
anyone obtaining the token can immediately obtain the information within
it. One of the four RPs referred to above sends an id token in addition
to the access token to its Google sign-in endpoint, and thus a passive web
attacker can retrieve the user information it contains without requesting it
from Google using the access token. We also found that one RP did not
enable SSL to protect its Google sign-in endpoint and returned user infor-
mation directly to the user browser. Another RP sends user information
back to its Google sign-in endpoint without SSL protection. Yet another
RP uses SSL to protect the link to the Google sign-in endpoint, but changes
to HTTP when it sends the user information back to the user browser. As a
result, user privacy cannot be guaranteed for 21% of the RPs we examined
(i.e. 7 out of 33). As noted above, a sniffer in Python was implemented to
demonstrate the feasibility of the attack.

4.1.5 Session Swapping

As discussed earlier, the RP Client running on the UA sends the user’s
OpenID tokens (i.e. one or more of a code, an access token, an id token,
and the user’s Google ID) back to its Google sign-in endpoint (see step 6 in
section 2.3.1). The OpenID Specification [37] recommends that a state value
should be appended when the RP Client sends the tokens back to its Google
sign-in endpoint, and that this state value should be bound to the browser
session. If the RP Client fails to send the state value, an attacker can execute
a session swapping attack [17, 41, 42] by performing the following steps.

1. The attacker first logs in to the RP website using his or her own ac-
count (see step 4 in section 2.3.1), and intercepts the tokens generated
by Google (see step 5 in section 2.3.1) .

2. The attacker constructs a request to the RP’s Google sign-in endpoint

including the attacker’s own tokens.

3. The attacker inserts the request in an HTML document (e.g. in the

src attribute of a img or iframe tag) which is made publicly available
via an HTTP server.

4. The victim user is now, by some means, induced to visit the website of-
fering the attacker’s web page. The HTML can be constructed in such
a way (described in detail below) that the victim’s UA will automati-
cally use the GET or POST method to send the attacker-constructed
request to the RP; as a result the user session on the RP website will
be bound to the attacker’s account.

We observed that 42% of the RP Clients using the Hybrid Server-side

Flow (i.e. 14 out of 33) use the POST method to submit the tokens back

13
to the RP’s server without an accompanying state value. Use of a static
img or iframe tag to perform an attack of the above type does not work
against these RPs, as the browser will automatically use the GET method to
retrieve the img and iframe data. Thus, in order to use the POST method
to submit those tokens, we created a special HTML page to conduct our
session-swapping attack. We used JavaScript to create an iframe with a
unique name in the browser. We then constructed a form inside the iframe
whose action points to the RP’s Google sign-in endpoint. We then put the
attacker’s tokens into the form input and configured the HTML to submit
the form whenever the HTML document is loaded into a browser.
To deploy the attack, the constructed HTML page is made available
via a publicly available web server. If a victim user visits this page, the
JavaScript inside the HTML automatically submits the attacker’s tokens to
the RP using the POST method; as a result the victim user’s session on
the RP is bound to the attacker’s, i.e. a session-swapping attack has been
performed. An attacker could use such an attack to collect sensitive user
information, e.g. if the victim user updates his credit card information on
the RP website, the credit card information will be written to the attacker’s
account.
Unfortunately, we found that 73% of RPs which adopt the Hybrid Server-
side Flow (i.e. 24 out of 33) are vulnerable to this attack. Of these 24
RPs, eight (i.e. 24% of this category) submit a code to their Google sign-in
endpoint; as the code is a one-time value, the attacker must update it within
the attack HTML every time the page is retrieved by a victim user. For the
other 48% of vulnerable RPs (i.e. 16 out of 33), an access token or the user’s
Google ID is submitted back to the Google sign-in endpoint, in which case
the attacker does not need to update the attack page HTML as frequently.

4.2 Studying the security of the Authorization Code Flow

We start by observing that Google’s OAuth 2.0 Authorization Code Flow
implementation [12] has similar steps to those given in 2.3.3. The token
endpoint provided as part of Google’s implementation of OAuth 2.0 (as
checked on April 22, 2015) returns an id token to the RP. That is, with-
out knowing details of the RP’s internal operation, we cannot distinguish
whether an RP is using OpenID Connect or OAuth 2.0. In this paper we
therefore cover all cases where Google returns a code to the RP’s Google
sign-in endpoint under our discussion of the OpenID Connect Authorization
Code Flow , even though some of the RPs concerned may actually be using
OAuth 2.0. However, this makes no difference to our security analysis.
Around 67% of the RPs we examined (i.e. 69 out of 103) use the Au-
thorization Code Flow . Unlike the Hybrid Server-side Flow , Google’s im-
plementation of Authorization Code Flow uses HTTP status code redirect
techniques (i.e. using code 302) to deliver the authorization response to the

14
RP’s Google sign-in endpoint.

4.2.1 Intercepting an access token

In the Authorization Code Flow , a code is returned by Google to the RP’s
Google sign-in endpoint (see step 6 in section 2.3.3). No tokens are trans-
mitted during the authorization procedure. After the RP receives the code,
it can use it to retrieve an access token from Google (steps 7/8 in 2.3.3); it
can then use the access token to retrieve user attributes from Google (step
9 in 2.3.3). The RP then logs the user in to its website.
If an RP does not use SSL to protect communications with its Google
sign-in endpoint, a passive web attacker may be able to intercept the code.
A passive web attacker cannot use the code to retrieve an access token from
Google, as it will not know the RP’s client secret (shared by the RP and
Google). However, we observed that, of the RPs using the Authorization
Code Flow , 6% of their Google sign-in endpoints (i.e. 4 out of 69) return
an access token to the user’s browser instead of binding the user to the
RP’s session. As these RPs do not use SSL to protect the transfer of the
access token, a passive web attacker is able to obtain the user’s access token
returned from the RP’s Google sign-in endpoint.

4.2.2 Stealing an access token via Cross-site Scripting

Google’s “automatic authorization granting” feature [41] generates an au-
thorization response automatically if the user has maintained a session with
Google and has previously granted permission for the RP concerned. Us-
ing this feature, an attacker might be able to steal a user access token by
exploiting an XSS vulnerability in the RP or the browser.
To test the feasibility of such an attack, an exploit written in JavaScript
was implemented. The exploit takes advantage of a recently revealed vul-
nerability in Android’s built-in browser [14] which allows an attacker to
conduct a universal XSS attack [30, 34, 43, 45]. The exploit uses a browser
window.open event to send a forged authorization request to Google’s au-
thorization server, within which response type=code (see step 2 in 2.3.3) is
changed to response type=code token id token. If the user is logged in to
his or her Google account and has previously granted permission for this
RP, Google automatically generates an authorization response without the
involvement of the user; this response is appended as a URI fragment (#) to
the redirect URI (see step 5 in section 2.3.3) and is sent back to the RP (see
step 6 in section 2.3.3). As the RP Google sign-in endpoint does not expect
an URI fragment, a predefined error page will be generated by the RP (e.g. a
‘404 not found’ or ‘Failed connection’ error). The exploiting JavaScript can
now extract the authorization response from the URL of the error page and
send it to its opener window, where the window.open event is triggered.

15
The opener window then sends the access token to the attacker’s server.
Unfortunately, our results show that all the RPs that adopt the Autho-
rization Code Flow are vulnerable to this attack. The vulnerability affects
all Android versions up to 4.4, which as of April 6, 2015 still accounted for
53.2% of Android devices5 .

4.2.3 Privacy Issues

Unlike the Hybrid Server-side Flow , only a code is submitted back to the
RP’s Google sign-in endpoint (see step 6 in section 2.3.3). No user informa-
tion (e.g. a Google ID or an id token) is transmitted during the authorization
procedure. However, user information leakage might nevertheless occur if
the RP Google sign-in endpoint sends the user information directly to the
user’s browser without SSL protection.
Our study revealed that 16% of RPs using the Authorization Code Flow
(i.e. 11 out of 69) return user information to the browser directly without
SSL protection. Thus a passive web attacker is able to intercept potentially
sensitive user information, e.g. if the user is using an open Wi-Fi network
(see section 3).

4.2.4 Session Swapping

If an RP using the Authorization Code Flow does not enable anti-CSRF
measures (e.g. by appending a state value bound to the browser session
to the tokens) to protect its Google sign-in endpoint, a web attacker can
launch a session swapping attack, precisely as described in 4.1.5 for the
Hybrid Server-side Flow .
Unlike the session swapping attack in 4.1.5, in the Authorization Code
Flow only the GET method is used to submit the code back to the RP’s
Google sign-in endpoint. This means that the attacker can simply insert
the forged request in the src attribute of a img or iframe tag of an HTML
document. When the victim user visits the malicious HTML, the browser
will automatically send the request to the RP’s Google sign-in endpoint
using the GET method.
We found that 35% of the RPs using the Authorization Code Flow (i.e.
24 out of 69) are vulnerable to this attack. However, as the code is a one
time value, the attacker has to update it every time the attack page is
visited by a victim user. As a result such an attack is not as harmful
as the session swapping attack in the Hybrid Server-side Flow , where an
access token which can be used multiple times is submitted back to the
RP’s Google sign-in endpoint.
5
https://developer.android.com/about/dashboards/index.html?utm_source=suzunone

16
4.2.5 Forcing a Login Using a CSRF attack
A CSRF login attack operates in the context of an ongoing interaction be-
tween a target web browser (running on behalf of a target user) and a target
RP. In such an attack, a malicious website somehow causes the target user’s
browser to initiate an OpenID Connect authorization request to the OP. Be-
cause of Google’s “automatic authorization granting” feature, receiving such
a request can cause the Google OP to generate an authorization response
which is delivered to the RP without the involvement of the user. If the
target user is currently logged in to Google, the browser will send cookies
containing the target user’s Google OP-generated tokens, along with the
attacker-supplied authorization request, to the OP. The OP will process
the malicious authorization request as if it was initiated by the target user,
and will generate an authorization response and send it to the RP. The
target browser could be made to send the spurious request in various ways;
for example, a malicious site visited by the browser could use the HTML
img tag’s src attribute to specify the URL of a malicious request, causing
the browser to silently use a GET method to send the request.
Our experiments have shown that 35% of the RPs which adopt the Au-
thorization Code Flow (i.e. 24 out of 69) are vulnerable to such an attack.
One consequence of this attack is that an attacker can cause a victim user
to log in to the RP, as long as the user has previously logged in to Google.
This could damage the user experience of the RP website, as the victim user
might dislike such a potentially annoying “automatic login” feature.

5 Discussion
OpenID Connect builds on top of the current web infrastructure, in which
web application vulnerabilities (e.g. cross-site request forgeries, cross-site
scripting) are common and have been widely exploited [2]. The existence of
these vulnerabilities exacerbates the threat posed by some of the implemen-
tation issues we have identified.
Most of the vulnerabilities described in section 4 are caused by a com-
bination of certain characteristics of the Google service and RP design de-
cisions that appear to value simplicity over security. We next consider in
greater detail how and why the various classes of vulnerability that we have
identified have arisen.

5.1 Customising the Hybrid-Server-side Flow

According to the OpenID Connect specification [37], a code must be returned
by the OP to the RP’s Google sign-in endpoint (see step 6 in section 2.3.1).
However, as described in section 4.1, many RPs using the Hybrid Server-
side Flow do not properly follow the specification, and in particular some

17
RP Clients submit an access token, an id token and/or a Google ID back
to their Google sign-in endpoints. It appears that the OpenID Connect
Specification only acts as a loose guideline for these RPs.
Meanwhile, the authorization request generated in the Hybrid Server-
side Flow by RPs which use Google’s OpenID Connect API will always
include response type=code token id token; therefore the authorization re-
sponse which is sent to the RP Client contains a code, access token and
id token. Unlike the Authorization Code Flow , where only a code is re-
turned to the RP’s Google sign-in endpoint (see step 6 in section 2.3.3) and
no RP Client exists, this gives the RP the ability to customise their Hybrid
Server-side Flow . In fact our experiments have shown that as many as 70%
of RPs (i.e. 23 out of 33) customise their Hybrid Server-side Flow . These
customisations potentially improve the performance of the OpenID Connect
system at the RP as well as enhancing the user experience, but they also risk
introducing new vulnerabilities into the system, e.g. allowing an attacker to
log in to the RP as any victim user (see section 4.1.1) and to impersonate
the victim user using an access token generated for another RP (see section
4.1.2). Moreover, as the code, access token and id token are returned by
Google inside a HTML document, these values are also revealed to the user
agent and hence to any applications (e.g. browser plug-ins), which might be
able to access the user agent. If the plug-in or user agent has vulnerabilities
which could allow an attacker to access these values, the attacker can steal
the user’s access token; for example a malicious plug-in which has the right
to read the content of HTML pages could obtain the access token.

5.2 Confusion over use of the state value in the Hybrid-

Server-side Flow
When RP developers construct the authorization request using the Google
OpenID Connect API, they only need to specify the RP client id and per-
mission scope in their code, as the other values in the authorization request
are handled by the API. These other values include the state, which is used
to bind the authorization response to the authorization request, thereby
preventing CSRF attacks [17, 29, 33, 46]. This simplifies the job of the RP
developers and makes support for Google’s OpenID Connect easier to im-
plement, but at the cost of increasing the attack surface and opening the
protocol to new vulnerabilities. In order to understand how the API deals
with the state value, we implemented an RP using the Google OpenID Con-
nect API. Surprisingly, we found that the state value extracted by the RP
Client is actually a null value; this means that Google itself fails to deliver
the state value to the RP Client, and hence the state value cannot be used
to mitigate the threat of a CSRF attack. We also observed that one of the
RPs using the Authorization Code Flow sends a null state value back to its
Google sign-in endpoint.

18
 As the state value generated by the Google OpenID Connect API is
not bound to the RP’s session and cannot be extracted by the RP Client,
another state value which is bound to the session needs to be implemented to
protect the RP’s Google sign-in endpoint against a CSRF attack. However,
73% of RPs using the Hybrid Server-side Flow fail to take this step. As a
result they are all vulnerable to the session swapping attack described in
section 4.1.5.
Google does recommend RPs to use a state value to protect their Google
sign-in endpoint. However, examination of the Google OpenID Connect
sample code [3] reveals that Google has not included a state value in its
example of an RP Client-generated AJAX request, which is used to send
data back to the RP [10]. The lack of a state parameter in the sample code
and the complexity of implementing anti-CSRF measures helps to explain
why 73% of the RPs using the Hybrid Server-side Flow are vulnerable to
this attack.

5.3 Automatic Authorization Granting

The “automatic authorization granting” feature of Google’s implementation
of OpenID Connect significantly enhances the user experience and system
performance. Without this feature, the user would have to click the “OK”
button in a popup window whenever he or she wished to log in to an RP,
in order to grant authorization. However, this feature can also be harmful,
since its use may allow an attacker to steal an access token (see section 4.2.2)
and force a user log in to the RP (see section 4.2.5).
We also observed that in the Hybrid Server-side Flow , iframes are used
to manage the session [5] between the RP Client and the OP. Suppose that
a user, who has previously both granted permission for the RP and logged
in to his or her Google account, visits the RP login page which contains
an iframe pointing to the authorization request. Because of the “automatic
authorization granting” feature, the browser can use the GET method to
retrieve the authorization response from Google without the involvement
of the user. The user agent and any applications (e.g. plug-ins) which can
access the user agent are able to extract the authorization response, which
might expose the Hybrid Server-side Flow to new attacks.

6 Recommendations
OpenID Connect has been deployed by many RPs and OPs, and it appears
that increasing numbers of RPs supporting the Google service will imple-
ment OpenID Connect for SSO now that Google has shut down its OpenID
service. However, our study has revealed serious vulnerabilities in existing
systems, and there is a significant danger that these vulnerabilities will be
replicated in future systems.

19
 Below we make a number of recommendations, directed at both RPs
and OPs, designed to address the vulnerabilities we have identified. These
recommendations primarily apply to RPs using the Google service and to the
Google OP itself, but some may have broader applicability. There are two
reasons for making these recommendations, namely both to try to address
the problems that exist in current systems, and to help ensure that future
systems are built in a more robust way.

6.1 Recommendations for RPs

When using the OpenID Connect system, especially in the case of the Hybrid
Server-side Flow , the RP’s developers are responsible for designing the RP
Client action upon receiving an authorization response from the Google
OP. As a result the security of the OpenID Connect system for the RP
largely depends on the security expertise of the RP developers. We have the
following recommendations for RPs.

• Do not customise the Hybrid Server-side Flow: One of the rea-

sons OpenID Connect is vulnerable to the attacks described in sections
4.1.1 and 4.1.2 is that the RPs customise the Hybrid Server-side Flow .
In particular, instead of submitting a code back to its Google sign-in
endpoint, the RP Client running the UA submits an access token or
Google ID, which is used by the RP to authenticate the user. Such
a customised Hybrid Server-side Flow might improve the user experi-
ence and the efficiency of the RP website, but at the cost of exposing
the system to new attacks. RPs must implement the OpenID Connect
Hybrid Server-side Flow strictly conforming to the OpenID Connect
Specification.

• Deploy countermeasures against CSRF attacks: One reason the

OpenID Connect systems we have investigated are vulnerable to CSRF
and session swapping attacks is that the RPs have not implemented
any of the well-known countermeasures to such attacks. In order to
prevent CSRF attacks, Google recommends RPs to include the state
parameter in the OpenID Connect authorization request and response,
and RPs should follow this recommendation.

• Do not use a constant or predictable state value: Some RPs in-

clude a fixed state value in the OpenID Connect authorization request.
If the state value is fixed, it cannot be uniquely bound to the browser
session, thereby allowing an attacker to successfully forge a response,
since the RP cannot distinguish between a legitimate response pro-
duced by a valid user and a forged response produced by an attacker.
Hence, in such a case, the inclusion of the state value does not protect
against CSRF attacks. Thus RPs must generate a non-guessable state

20
 value which should be bound to the browser session so that the state
value can used to verify the validity of the response.

6.2 Recommendations for OPs

In an OpenID Connect SSO system, the OP designs the process and provides
the API for RPs. An RP wishing to support a particular OP must therefore
comply with the requirements of that OP, and so the OPs play a critical
role in the system. We have the following recommendations for OPs (and
in particular for Google).

• Remove the token from the authorization request in the Hy-

brid Server Flow: In the Hybrid Server-side Flow , the token in the
authorization request causes Google to return an access token to the
RP Client. This allows RP Clients to submit an access token back
to their Google sign-in endpoints, as was the case for 58% of RPs us-
ing the Hybrid Server-side Flow that we investigated. This practice
gives rise to a range of possible impersonation attacks. Sending the
access token also creates further risks, since if the RP does not enable
SSL to protect its Google sign-in endpoint, a passive network attacker
could steal it. This would not only enable a malicious RP to imperson-
ate a user to those RPs which submit an access token to the Google
sign-in endpoint, but also allow the possibility of other misuses of this
token, e.g. to compromise sensitive user data.

• Add a state value to the sample code: OPs typically provide

sample code to help RP developers make their website interact ap-
propriately with the OP. As we discovered, Google does not include
a state value in its sample code for the Hybrid Server-side Flow . It
seems reasonable to speculate that this is the main reason why 73% of
the RP-OP interactions we have analysed (see section 4.1.5) are vul-
nerable to session swapping attacks. However, for cases where a state
value is included in Google’s sample code, this number fell to 35% (see
section 4.2.4).

• Allow the RP to specify the state value in the Hybrid Server

Flow: The state value in the authorization request of the Hybrid
Server-side Flow is automatically handled by the Google OpenID Con-
nect API. However, the RP Client cannot extract the state as it is
a null value. As the state value is not bound to the browser session,
it does not protect the RP against CSRF attacks. It would probably
be better to let the RP handle the state value rather than the Google
API handle it. In addition, Google should check the source code of its
postmessage.js script to ensure that the state value can be extracted
by the RP Client.

21
6.3 Notifying affected parties
We reported the issues described in section 4.1.1 to the three affected parties
in February and also provided advice to help them fix the problem. As
of 30 July 2015, one of the three has fixed the problem, one has ignored
our warning, and the third terminated support for the Google SSO service.
On April 17th 2015 we also notified Google of all the issues described in
this paper. Google acknowledged the problem described in section 5.2 and
notified their OpenID Connect group.

7 Related Work
OAuth 2.0, as the predecessor of OpenID Connect, has been analysed using
formal methods. Pai et al. [35] confirmed a security issue described in the
OAuth 2.0 Thread Model [32] using the Alloy Framework [26]. Chari et al.
analysed OAuth 2.0 in the Universal Composability Security framework [21]
and showed that OAuth 2.0 is secure if all the communications links are
SSL-protected. Frostig and Slack [39] discovered a cross site request forgery
attack in the Implicit Grant flow of OAuth 2.0, using the Murphi framework
[24]. Bansal et al. [15] analysed the security of OAuth 2.0 using the WebSpi
[16] and ProVerif models [19]. However, all this work is based on abstract
models of OAuth 2.0, and so delicate implementation details are ignored.
Meanwhile, a range of work exploring the security properties of real-
world implementations of OAuth 2.0 has also been conducted. Wang et
al. [44] examined a number of deployed SSO systems, focussing on a logic
flaw present in many such systems, including OpenID. In parallel, Sun and
Beznosov [41] also studied deployed systems of OAuth 2.0 providing services
in English. Li and Mitchell [31] examined the security of deployed OAuth
2.0 systems providing services in Chinese. In parallel, Zhou and Evans [47]
conducted a large scale study of the security of Facebook’s OAuth 2.0 imple-
mentation. Chen et al. [22], and Shehab and Mohsen [38] have looked at the
security of the implementation of OAuth 2.0 on mobile platforms. However,
despite all the work on OAuth, very little research has been conducted on
the security of OpenID Connect systems.

8 Concluding Remarks
In this paper, we have reported on the first field study of the security prop-
erties of Google’s implementation of OpenID Connect. We examined the se-
curity of all 103 of the RPs that implement support for the Google OpenID
Connect service from the GTMetrix list of the Top 1000 Sites. The method-
ology we used to discover vulnerabilities is similar to that used by Wang
et al. [44] and Sun and Beznosov [41], i.e. we analysed the HTTP mes-

22
sages transmitted between the RP and OP via the browser; however, our
approach was different in two key respects. First, we added a further class
of adversary to the threat model, in which a malicious RP tries to collect
user access tokens and then use them to impersonate the user to other RPs.
Second, we focussed our study on OpenID Connect rather than OAuth 2.0
and other generic SSO systems. This has allowed us to to identify gaps
between the implementation and specification of OpenID Connect, discover
a number of vulnerabilities which allow an attack to log in to the RP as a
victim user, and propose practical and useful improvements which can be
adopted by all OpenID Connect RPs and OPs.

References
[1] HTML5 Web Messaging, 2012. http://www.w3.org/TR/2012/WD-webmessaging-20120313/.

[2] OWASP Top Ten Project, 2013. https://www.owasp.org/index.php/Top10#OWASP_Top_10_fo

[3] Google OpenID Connect Hybrid Server-side Flow, 2014.

https://developers.google.com/+/web/signin/.

[4] Microsoft OpenID Connect, 2014. https://msdn.microsoft.com/en-us/library/azure/dn645

[5] OpenID Connect Session Management, 2014.

http://openid.net/specs/openid-connect-session-1_0.html.

[6] PayPal OpenID Connect 1.0, 2014.

https://developer.paypal.com/docs/integration/direct/identity/log-in-with-paypal

[7] Google OAuth 2.0 Client-side, 2015.

https://developers.google.com/identity/protocols/OAuth2UserAgent?hl=es.

[8] Google OpenID 2.0, 2015. https://developers.google.com/accounts/docs/OpenID.

[9] Google OpenID Connect 1.0, 2015.

https://developers.google.com/accounts/docs/OpenIDConnect.

[10] Google OpenID Connect Server-side Flow, 2015.

https://developers.google.com/+/web/signin/server-side-flow.

[11] GTmetrix Top 1000 Sites, 2015. http://gtmetrix.com/top1000.html.

[12] OAuth 2.0 Authorization Code Flow, 2015.

https://developers.google.com/identity/protocols/OAuth2WebServer.

[13] Verify ID Tokens, 2015. https://www.tbray.org/ongoing/When/201x/2013/04/04/ID-Tokens

[14] Rafay Baloch. Android Browser Same Origin Policy Bypass, 2014.
http://www.rafayhackingarticles.net/2014/08/android-browser-same-origin-policy.

23
[15] Chetan Bansal, Karthikeyan Bhargavan, Antoine Delignat-Lavaud, and
Sergio Maffeis. Discovering concrete attacks on website authorization
by formal analysis. Journal of Computer Security, 22(4):601–657, 2014.

[16] Chetan Bansal, Karthikeyan Bhargavan, and S. Maf-

feis. WebSpi and web application models, 2011.
http://prosecco.gforge.inria.fr/webspi/CSF/.

[17] Adam Barth, Collin Jackson, and John C Mitchell. Robust defenses for
cross-site request forgery. In Peng Ning, Paul F. Syverson, and Somesh
Jha, editors, Proceedings of the 2008 ACM Conference on Computer
and Communications Security, CCS 2008, Alexandria, Virginia, USA,
October 27-31, 2008, pages 75–88. ACM, 2008.

[18] Adam Barth, Collin Jackson, and John C. Mitchell. Securing frame
communication in browsers. Commun. ACM, 52(6):83–91, 2009.

[19] Bruno Blanchet and Ben Smyth. ProVerif: Cryp-

tographic protocol verifier in the formal model.
http://prosecco.gforge.inria.fr/personal/bblanche/proverif/.

[20] David Chappell. Introducing windows cardspace. 2006.

http://msdn.microsoft.com/en-us/library/aa480189.aspx.

[21] Suresh Chari, Charanjit S Jutla, and Arnab Roy. Universally compos-
able security analysis of OAuth v2.0. IACR Cryptology ePrint Archive,
2011:526, 2011.

[22] Eric Y. Chen, Yutong Pei, Shuo Chen, Yuan Tian, Robert Kotcher, and
Patrick Tague. Oauth demystified for mobile application developers.
In Gail-Joon Ahn, Moti Yung, and Ninghui Li, editors, Proceedings of
the 2014 ACM SIGSAC Conference on Computer and Communications
Security, Scottsdale, AZ, USA, November 3-7, 2014, pages 892–903.
ACM, 2014.

[23] Philippe De Ryck, Lieven Desmet, Wouter Joosen, and Frank Piessens.
Automatic and precise client-side protection against CSRF attacks. In
Vijay Atluri and Claudia Dı́az, editors, Computer Security - ESORICS
2011 - 16th European Symposium on Research in Computer Security,
Leuven, Belgium, September 12-14, 2011. Proceedings, volume 6879 of
Lecture Notes in Computer Science, pages 100–116. Springer, 2011.

[24] David L Dill. The murphi verification system. In Rajeev Alur and
Thomas A. Henzinger, editors, Computer Aided Verification, 8th In-
ternational Conference, CAV ’96, New Brunswick, NJ, USA, July 31 -
August 3, 1996, Proceedings, volume 1102 of Lecture Notes in Computer
Science, pages 390–393. Springer, 1996.

24
[25] Dick Hardt. The OAuth 2.0 authorization framework. October 2012.
http://tools.ietf.org/html/rfc6749.
[26] Daniel Jackson. Alloy 4.1, 2010. http://alloy.mit.edu/community/.
[27] M Jones and Dick Hardt, editors. The OAuth 2.0
Authorization Framework: Bearer Token Usage, 2012.
https://tools.ietf.org/html/rfc6750.
[28] Michael Jones, Nat Sakimura, and John
Bradley. JSON Web Token (JWT), 2014.
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-21.
[29] Nenad Jovanovic, Engin Kirda, and Christopher Kruegel. Preventing
cross site request forgery attacks. In Second International Conference
on Security and Privacy in Communication Networks and the Work-
shops, SecureComm 2006, Baltimore, MD, Aug. 28 2006 - September
1, 2006, pages 1–10. IEEE, 2006.
[30] Engin Kirda, Christopher Krügel, Giovanni Vigna, and Nenad Jo-
vanovic. Noxes: a client-side solution for mitigating cross-site script-
ing attacks. In Hisham Haddad, editor, Proceedings of the 2006 ACM
Symposium on Applied Computing (SAC), Dijon, France, April 23-27,
2006, pages 330–337. ACM, 2006.
[31] Wanpeng Li and Chris J. Mitchell. Security issues in OAuth 2.0 SSO
implementations. In Sherman S. M. Chow, Jan Camenisch, Lucas
Chi Kwong Hui, and Siu-Ming Yiu, editors, Information Security -
17th International Conference, ISC 2014, Hong Kong, China, October
12-14, 2014. Proceedings, volume 8783 of Lecture Notes in Computer
Science, pages 529–541. Springer, 2014.
[32] Torsten Lodderstedt, Mark McGloin, and Phil Hunt.
OAuth 2.0 Threat Model and Security Considerations, 2013.
http://tools.ietf.org/html/rfc6749.
[33] Ziqing Mao, Ninghui Li, and Ian Molloy. Defeating cross-site request
forgery attacks with browser-enforced authenticity protection. In Roger
Dingledine and Philippe Golle, editors, Financial Cryptography and
Data Security, 13th International Conference, FC 2009, Accra Beach,
Barbados, February 23-26, 2009. Revised Selected Papers, volume 5628
of Lecture Notes in Computer Science, pages 238–255. Springer, 2009.
[34] Yacin Nadji, Prateek Saxena, and Dawn Song. Document structure in-
tegrity: A robust basis for cross-site scripting defense. In Proceedings of
the Network and Distributed System Security Symposium, NDSS 2009,
San Diego, California, USA, 8th February - 11th February 2009. The
Internet Society, 2009.

25
[35] Suhas Pai, Yash Sharma, Sunil Kumar, Radhika M Pai, and Sanjay
Singh. Formal verification of OAuth 2.0 using Alloy framework. In
Proceedings of the International Conference on Communication Sys-
tems and Network Technologies (CSNT), 2011, pages 655–659. IEEE,
2011.

[36] David Recordon and Brad Fitzpatrick.

OpenID Authentication 2.0 — Final, 2007.
http://openid.net/specs/openid-authentication-2_0.html.

[37] Nat Sakimura, John Bradley, Michael Jones, Breno de Medeiros,

and Mortimore Chuck. OpenID Connect Core 1.0, 2014.
http://openid.net/specs/openid-connect-core-1_0.html.

[38] Mohamed Shehab and Fadi Mohsen. Securing OAuth implementations

in smart phones. In Elisa Bertino, Ravi S. Sandhu, and Jaehong Park,
editors, Fourth ACM Conference on Data and Application Security and
Privacy, CODASPY’14, San Antonio, TX, USA - March 03 - 05, 2014,
pages 167–170. ACM, 2014.

[39] Quinn Slack and Roy Frostig. Murphi Analysis of OAuth 2.0 Implicit
Grant Flow, 2011. http://www.stanford.edu/class/cs259/WWW11/.

[40] Sooel Son and Vitaly Shmatikov. The postman always rings twice:
Attacking and defending postmessage in HTML5 websites. In 20th
Annual Network and Distributed System Security Symposium, NDSS
2013, San Diego, California, USA, February 24-27, 2013. The Internet
Society, 2013.

[41] San-Tsai Sun and Konstantin Beznosov. The devil is in the (imple-
mentation) details: An empirical analysis of OAuth SSO systems. In
Ting Yu, George Danezis, and Virgil D. Gligor, editors, the ACM Con-
ference on Computer and Communications Security, CCS ’12, Raleigh,
NC, USA, October 16-18, 2012, pages 378–390. ACM, 2012.

[42] Bart van Delft and Martijn Oostdijk. A security analysis of OpenID.
In Elisabeth de Leeuw, Simone Fischer-Hübner, and Lothar Fritsch,
editors, Policies and Research in Identity Management - Second IFIP
WG 11.6 Working Conference, IDMAN 2010, Oslo, Norway, November
18-19, 2010. Proceedings, volume 343 of IFIP Advances in Information
and Communication Technology, pages 73–84. Springer, 2010.

[43] Philipp Vogt, Florian Nentwich, Nenad Jovanovic, Engin Kirda,

Christopher Krügel, and Giovanni Vigna. Cross site scripting preven-
tion with dynamic data tainting and static analysis. In Proceedings of
the Network and Distributed System Security Symposium, NDSS 2007,

26
 San Diego, California, USA, 28th February - 2nd March 2007. The
Internet Society, 2007.

[44] Rui Wang, Shuo Chen, and XiaoFeng Wang. Signing me onto your ac-
counts through facebook and google: A traffic-guided security study of
commercially deployed single-sign-on web services. In IEEE Symposium
on Security and Privacy, SP 2012, 21-23 May 2012, San Francisco,
California, USA, pages 365–379. IEEE Computer Society, 2012.

[45] Gary Wassermann and Zhendong Su. Static detection of cross-site

scripting vulnerabilities. In Wilhelm Schäfer, Matthew B. Dwyer, and
Volker Gruhn, editors, 30th International Conference on Software Engi-
neering (ICSE 2008), Leipzig, Germany, May 10-18, 2008, pages 171–
180. ACM, 2008.

[46] William Zeller and Edward W Felten. Cross-site request forgeries: Ex-
ploitation and prevention. Bericht, Princeton University, 2008.

[47] Yuchen Zhou and David Evans. SSOScan: Automated testing of web
applications for Single Sign-On vulnerabilities. In Kevin Fu and Jaeyeon
Jung, editors, Proceedings of the 23rd USENIX Security Symposium,
San Diego, CA, USA, August 20-22, 2014., pages 495–510. USENIX
Association, 2014.

27

View publication stats