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

Fett, Daniel; Küsters, Ralf; Schmitz, Guido

doi:10.1109/csf.2017.20

Cited by 58 publications

(89 citation statements)

References 34 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Nonetheless, our session integrity property here is stronger than those used in [6], [7] in the sense that we define (and prove) session integrity not only in the presence of web attackers, but also for the much stronger network attacker. (This is enabled by using the __Secureprefix for cookies.…”

Section: Definition 1 (Access Token Associated With C As and Id)mentioning

confidence: 99%

“…In TLS client authentication, not only the server authenticates to the client (as is common for TLS) but the client also authenticates to the server. To this end, the client proves 7 If it is assumed that the authorization request never leaks to the attacker, it is sufficient and allowed by RFC 7636 to use the verifier as the challenge, i.e., without hashing. 8 As noted in [32], Section 5.1 this extension supports all TLS versions with certificate-based client authentication.…”

Section: Client Authentication Using Jws Client Assertionsmentioning

confidence: 99%

“…The Web Infrastructure Model (WIM) was introduced by Fett, Küsters, and Schmitz in [22] (therefore also called the FKS model) and further developed in subsequent work. The appendix of [44] provides a detailed description of the model; a comparison with other models and a discussion of its scope and limitations can be found in [22]- [24]. We here only give a brief overview of the WIM following the description in [7], with some more details presented in Appendix B.…”

Section: A the Web Infrastructure Modelmentioning

confidence: 99%

“…Contributions of this Paper: We build a detailed formal model of the FAPI based on a comprehensive formal model of the web infrastructure proposed by Fett et al in [22], which we refer to as the Web Infrastructure Model (WIM). The WIM has been successfully used to find vulnerabilities in and prove the security of several web applications and standards [6], [7], [22]- [24]. It captures a wide set of web features from DNS to JavaScript in unrivaled detail and comprehensiveness.…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

An Extensive Formal Security Analysis of the OpenID Financial-Grade API

Fett

Hosseyni

Küsters

2019

2019 IEEE Symposium on Security and Privacy (SP)

Self Cite

View full text Add to dashboard Cite

Forced by regulations and industry demand, banks worldwide are working to open their customers' online banking accounts to third-party services via web-based APIs. By using these so-called Open Banking APIs, third-party companies, such as FinTechs, are able to read information about and initiate payments from their users' bank accounts. Such access to financial data and resources needs to meet particularly high security requirements to protect customers.One of the most promising standards in this segment is the OpenID Financial-grade API (FAPI), currently under development in an open process by the OpenID Foundation and backed by large industry partners. The FAPI is a profile of OAuth 2.0 designed for high-risk scenarios and aiming to be secure against very strong attackers. To achieve this level of security, the FAPI employs a range of mechanisms that have been developed to harden OAuth 2.0, such as Code and Token Binding (including mTLS and OAUTB), JWS Client Assertions, and Proof Key for Code Exchange.In this paper, we perform a rigorous, systematic formal analysis of the security of the FAPI, based on an existing comprehensive model of the web infrastructure-the Web Infrastructure Model (WIM) proposed by Fett, Küsters, and Schmitz. To this end, we first develop a precise model of the FAPI in the WIM, including different profiles for read-only and read-write access, different flows, different types of clients, and different combinations of security features, capturing the complex interactions in a webbased environment. We then use our model of the FAPI to precisely define central security properties. In an attempt to prove these properties, we uncover partly severe attacks, breaking authentication, authorization, and session integrity properties. We develop mitigations against these attacks and finally are able to formally prove the security of a fixed version of the FAPI.Although financial applications are high-stakes environments, this work is the first to formally analyze and, importantly, verify an Open Banking security profile.By itself, this analysis is an important contribution to the development of the FAPI since it helps to define exact security properties and attacker models, and to avoid severe security risks before the first implementations of the standard go live.Of independent interest, we also uncover weaknesses in the aforementioned security mechanisms for hardening OAuth 2.0. We illustrate that these mechanisms do not necessarily achieve the security properties they have been designed for.

show abstract

Section: Definition 1 (Access Token Associated With C As and Id)mentioning

confidence: 99%

Section: Client Authentication Using Jws Client Assertionsmentioning

confidence: 99%

Section: A the Web Infrastructure Modelmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

An Extensive Formal Security Analysis of the OpenID Financial-Grade API

Fett

Hosseyni

Küsters

2019

2019 IEEE Symposium on Security and Privacy (SP)

Self Cite

View full text Add to dashboard Cite

show abstract

“…This formal analysis revealed two unknown attacks on OAuth that violate the authorization and authentication properties. A similar analysis is performed for OpenID Connect in [32]. Two other examples of formalizations of OAuth are [33], where the different OAuth flows are modeled in the Applied Pi calculus and verified using ProVerif extended with WebSpi (a library that models web users, apps and intruders), and [34], where OAuth is modeled in Alloy.…”

Section: Related Workmentioning

confidence: 99%

Design, Formal Specification and Analysis of Multi-Factor Authentication Solutions with a Single Sign-On Experience

Sciarretta

Carbone²,

Ranise³

et al. 2018

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract.Over the last few years, there has been an almost exponential increase of the number of mobile applications that deal with sensitive data, such as applications for e-commerce or health. When dealing with sensitive data, classical authentication solutions based on usernamepassword pairs are not enough, and multi-factor authentication solutions that combine two or more authentication elements of different categories are required. Many different such solutions are available, but they usually cover the scenario of a user accessing web applications on their laptops, whereas in this paper we focus on native mobile applications. This changes the exploitable attack surface and thus requires a specific analysis. In this paper, we present the design, the formal specification and the security analysis of a solution that allows users to access different mobile applications through a multi-factor authentication solution providing a Single Sign-On experience. The formal and automated analysis that we performed validates the security goals of the solution we propose.

show abstract

Inter‐cloud secure data sharing and its formal verification

Zhang

Yang

et al. 2021

Trans Emerging Tel Tech

View full text Add to dashboard Cite

With the development of cloud computing, data sharing and collaboration have become increasing among cloud‐oriented organizations. In addition to trivial management work, data providers face many difficulties in managing access control policies in cloud data sharing, to prevent permission abuse and information leakage. This article mainly answers the following question: is it possible to achieve verifiably secure inter‐cloud data sharing? This article proposes an inter‐cloud data sharing (ICDS) approach based on ciphertext‐policy attribute‐based encryption (CP‐ABE) to ensure the security of ICDS. The security properties that ICDS holds are formally verified, where the information flow rules are defined and used in the verification. The information flow of the proposed ICDS is firstly modeled by use of high‐level Petri nets (HLPN) formally, then being represented in Z language, and at last the security properties of ICDS are verified by the Z3 solver. The formal analysis proves that the ICDS holds the security properties of confidentiality, authenticity, and collusion‐resistance.

show abstract

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

Cited by 58 publications

References 34 publications

An Extensive Formal Security Analysis of the OpenID Financial-Grade API

An Extensive Formal Security Analysis of the OpenID Financial-Grade API

Design, Formal Specification and Analysis of Multi-Factor Authentication Solutions with a Single Sign-On Experience

Inter‐cloud secure data sharing and its formal verification

Contact Info

Product

Resources

About