Analysing the Security of Google's implementation of OpenID Connect

TL;DR

This paper presents a large-scale analysis of Google's OpenID Connect implementation, revealing significant security vulnerabilities that can be exploited to impersonate users, and offers practical recommendations for improving security.

Contribution

It provides the first comprehensive forensic study of Google's OpenID Connect deployment, identifying specific vulnerabilities caused by design choices and implementation decisions.

Findings

Multiple vulnerabilities allow attacker login as victims

Vulnerabilities stem from Google's design and developer choices

Recommendations provided to enhance real-world OpenID Connect security

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 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 simplicity of implementation. We also give practical recommendations for both RPs and OPs to help improve the security of real world OpenID Connect systems.