Analysing the Security of Google’s Implementation of OpenID Connect

Abstract

Many millions of users routinely use their Google accounts to log in to relying party (RP) websites supporting the Google OpenID Connect 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 authenticity 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 practical study of Google's implementation of OpenID Connect, involving forensic examination of 103 RP websites which support its use for signin. 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 simplicity of implementation. We also give practical recommendations for both RPs and OPs to help improve the security of real world OpenID Connect systems.

Mitigating CSRF attacks on OAuth 2.0 Systems

“…Chen et al [6], and Shehab and Mohsen [19] have looked at the security of OAuth 2.0 implementations on mobile platforms. Li and Mitchell [14] conducted an empirical study of the security of the OpenID Connect-based SSO service provided by Google.…”

“…The HTTP message (see, for example, listing 1.1) of such an authorization response contains a Referer header which points to the IdP domain. In practice, major IdPs, such as Google, Facebook and Microsoft, implement an 'automatic authorization granting' feature [14]. That is, when the user has logged in to his/her OAuth 2.0 IdP account, the IdP generates an authorization response without explicit user consent.…”

Your Code Is My Code: Exploiting a Common Weakness in OAuth 2.0 Implementations

“…The security properties of real-world OAuth 2.0 implementations have also been examined by a number of authors [5,10,11,13,18,21,22,24]. Wang et al [22] examined deployed SSO systems, focussing on a logic flaw present in many such systems, including OpenID.…”

Choice of suitable Identity and Access Management standards for mobile computing and communication

“…An XSS attack in OIDC, an attacker exploits the facility of an automatic authorization granting by which an automatic authorization response is created if a user had recently a session with the OIDC IdP and previously granted authorization for the same client/RP [31]. Using this facility, an attacker may be able to steal a user ac-cess token by exploiting an XSS vulnerability in the client/RP side.…”