The Web SSO Standard OpenID Connect: In-Depth Formal Security Analysis and Security Guidelines

Web-based single sign-on (SSO) services such as Google Sign-In and Log In with Paypal are based on the OpenID Connect protocol. This protocol enables so-called relying parties to delegate user authentication to so-called identity providers. OpenID Connect is one of the newest and most widely deployed single sign-on protocols on the web. Despite its importance, it has not received much attention from security researchers so far, and in particular, has not undergone any rigorous security analysis. In this paper, we carry out the first in-depth security analysis of OpenID Connect. To this end, we use a comprehensive generic model of the web to develop a detailed formal model of OpenID Connect. Based on this model, we then precisely formalize and prove central security properties for OpenID Connect, including authentication, authorization, and session integrity properties. In our modeling of OpenID Connect, we employ security measures in order to avoid attacks on OpenID Connect that have been discovered previously and new attack variants that we document for the first time in this paper. Based on these security measures, we propose security guidelines for implementors of OpenID Connect. Our formal analysis demonstrates that these guidelines are in fact effective and sufficient.Comment: An abridged version appears in CSF 2017. Parts of this work extend the web model presented in arXiv:1411.7210, arXiv:1403.1866, arXiv:1508.01719, and arXiv:1601.0122

Analysing the Security of Google's implementation of OpenID Connect

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

Model of NFT Implementation on Web SSO over OpenID Connect and Oauth 2.0 protocols

Single Sign-On (SSO) is a mechanism that allows users to access various services using a single set of login credentials. However, in SSO implementations, there are still challenges related to security and authentication management, particularly attacks targeting the Identity Provider (IDP). To address this, the use of Non-Fungible Tokens (NFTs) as proof of IDP ownership has been proposed as a solution to enhance security in the authentication mechanism. The utilization of NFTs in SSO with OpenID Connect and OAuth 2.0 has the potential to improve security and convenience in the authentication process due to the unique and non-duplicable nature of NFTs. The results of this research present a model and design of SSO with NFTs on OpenID Connect and OAuth 2.0. An SSO application with login, register, and password recovery features was also developed to provide convenience to users during the login process. The findings conclude that the utilization of NFTs in SSO with OpenID Connect and OAuth 2.0 has the potential to enhance security and convenience in the authentication mechanism. Further research is needed to explore aspects such as scalability, in-depth security analysis, testing in real-world scenarios, improvement of integration and interoperability, as well as comparative analysis with other SSO technologies

Do not trust me: Using malicious IdPs for analyzing and attacking Single Sign-On

Single Sign-On (SSO) systems simplify login procedures by using an an Identity Provider (IdP) to issue authentication tokens which can be consumed by Service Providers (SPs). Traditionally, IdPs are modeled as trusted third parties. This is reasonable for SSO systems like Kerberos, MS Passport and SAML, where each SP explicitely specifies which IdP he trusts. However, in open systems like OpenID and OpenID Connect, each user may set up his own IdP, and a discovery phase is added to the protocol flow. Thus it is easy for an attacker to set up its own IdP. In this paper we use a novel approach for analyzing SSO authentication schemes by introducing a malicious IdP. With this approach we evaluate one of the most popular and widely deployed SSO protocols - OpenID. We found four novel attack classes on OpenID, which were not covered by previous research, and show their applicability to real-life implementations. As a result, we were able to compromise 11 out of 16 existing OpenID implementations like Sourceforge, Drupal and ownCloud. We automated discovery of these attacks in a open source tool OpenID Attacker, which additionally allows fine-granular testing of all parameters in OpenID implementations. Our research helps to better understand the message flow in the OpenID protocol, trust assumptions in the different components of the system, and implementation issues in OpenID components. It is applicable to other SSO systems like OpenID Connect and SAML. All OpenID implementations have been informed about their vulnerabilities and we supported them in fixing the issues

Layered identity infrastructure model for identity meta systems

There are several Identity Meta Systems emerging in the identity management field, such as CardSpace and Higgins Trust Framework. The goal of an Identity Meta System (IMetS) is to integrate existing or new Identity Management System (IMS) to provide users with seamless interoperability and a consistent user experience. IMetS is a complex system that tries to integrate the already complicated IMS services. With such a complex system, we need a way to assess IMetS in order to determine how well an IMetS integrates the various IMS services. However, as IMetS is a rela- tively new concept, there is no framework to identify the properties that an ideal IMetS should have. The contribution of this paper is to introduce the Layered Identity Infrastructure Model (LIIM) that can be used as a framework to assess IMetS. In addition, the LIIM framework can also be used to identify the missing components of an IMetS, to guide and improve the design of an existing IMetS, to serve as a design benchmark for a new IMetS, as well as to aid the understanding of a complicated IMetS

An Expressive Model for the Web Infrastructure: Definition and Application to the BrowserID SSO System

The web constitutes a complex infrastructure and as demonstrated by numerous attacks, rigorous analysis of standards and web applications is indispensable. Inspired by successful prior work, in particular the work by Akhawe et al. as well as Bansal et al., in this work we propose a formal model for the web infrastructure. While unlike prior works, which aim at automatic analysis, our model so far is not directly amenable to automation, it is much more comprehensive and accurate with respect to the standards and specifications. As such, it can serve as a solid basis for the analysis of a broad range of standards and applications. As a case study and another important contribution of our work, we use our model to carry out the first rigorous analysis of the BrowserID system (a.k.a. Mozilla Persona), a recently developed complex real-world single sign-on system that employs technologies such as AJAX, cross-document messaging, and HTML5 web storage. Our analysis revealed a number of very critical flaws that could not have been captured in prior models. We propose fixes for the flaws, formally state relevant security properties, and prove that the fixed system in a setting with a so-called secondary identity provider satisfies these security properties in our model. The fixes for the most critical flaws have already been adopted by Mozilla and our findings have been rewarded by the Mozilla Security Bug Bounty Program.Comment: An abridged version appears in S&P 201