MISO: Legacy-compatible Privacy-preserving Single Sign-on using Trusted Execution Environments

1.   Introduction

"The end of passwords" is nominated as one of the ten breakthrough technologies in 2022 by MIT Technology Review ^[1], as its wide adoption may finally put an end to the perennial breaches caused by improper uses of passwords (see, e.g., ^[2] for a survey). Among the proposed passwordless authentication techniques (e.g., biometrics, hardware tokens, magic links, etc.), single sign-on (SSO) —with which users can authenticate to third-party applications through a central identity provider—stands out with unique advantages: it offers a familiar user experience, it does not require special hardware, and it is already widely supported. As of 2022, more than 84,000 websites support SSO through Google and more than 80,000 through Facebook ^[3].

At a higher level, SSO is a three-party protocol among a user , an Identity Provider (referred to as IdP for short), and a third-party application (referred to as a Relying Party or RP) to which the user wishes to authenticate. In order for the RP to authenticate the user, it redirects the user to an IdP, who authenticates the user through established means (e.g., password, QR codes, etc.) and informs the RP of the user’s identity (typically by providing a token). One of the most widely adopted SSO protocols today is OAuth 2.0 ^[4],[5], supported by popular IdPs like Facebook, Twitter, Apple, and Microsoft ^[6]–^[9].

While SSO is widely adopted, deployed systems suffer from several well recognized security and privacy problems ^[10]–^[17]:

1. ■ Account linkage by identity providers (IdPs) ^[12],[14]–^[16]. Positioned at the center of the SSO workflow, identity providers (IdPs) have significant surveillance power. In particular, they can track which websites users visit, contributing to the massive scale of data that big tech firms already possess.
2. ■ Account linkage across relying parties (RPs) ^[10][18], [§17.3] ^[19], [§3.3]. In existing SSO systems ^[6],[20], IdPs identify users with the same unique user identifiers across RPs, which allows a group of colluding RPs to track a given user’s login activities across websites.
3. ■ Unnecessary identifier exposure to RPs ^[10]–^[13],[17]. While existing SSO systems give users some control over what to disclose to the RPs, many reveal unique identifiers (e.g., email) unconditionally. This is neither necessary for many applications nor desirable. For example, Tiktok ^[21] does not need user emails, but is nonetheless provided with one when a user registers through Google SSO.
4. ■ Single-point failures of account security and availability ^[12],[14]. As the name suggests, SSO relies on a single IdP, which implies strong assumptions about the security and availability of the account on that IdP. This can be undesirable for crucial applications (e.g., cryptocurrency wallet ^[22]), where account compromise can be catastrophic. Service downtime can also render users unable to access third-party applications. A better approach is to allow users to choose multiple IdPs (potentially in a threshold fashion for better availability). Although RPs often offer several IdP choices, users can only select a single IdP to log in, and each IdP option creates a separate account. So far, there is no solution to support multiple IdPs while achieving the aforementioned privacy goals.

It is important to note that these issues are well recognized and several solutions have been proposed (e.g., SPRESSO ^[23], PRIMA ^[24], POIDC ^[19], EL PASSO ^[25], and UPPRESSO ^[26]). However, to the best of our knowledge, none of these academic solutions has seen the light of real-world adoption. A key reason is that they lack legacy compatibility —these solutions require the identity providers to deploy new software, which creates a significant adoption barrier.

Meanwhile, solutions do get deployed only solved part of the problems. For example, OIDC with Pairwise Pseudonymous Identifiers introduced in OpenID Connect 1.0 ^[27] can prevent account linkage across RPs, but it does not eliminate other privacy issues. Similarly, Apple ^[8],[28] launched "Sign in with Apple" in 2019, an SSO service that auto-generates a random forward email address for each RP to hide user email and prevent cross-RP linkage, but Apple (as the IdP) can still track users’ login activities.

Figure 1:Figure 1: Login with MISO under different settings: (a) a single IdP; (b) multiple IdPs.

In this paper, we aim to combine the best of both worlds: can we design an SSO protocol that not only achieves strong privacy guarantees, but also remains fully compatible with existing identity providers?

Our solution: MISO

We start with addressing the issue of account linkage by IdP and extend the basic protocol to address other privacy issues. Our key idea is to build a mixer to shield users from identity providers. (MISO stands for a mixer of SSO.) Figure 1(a) illustrates the high-level idea. Suppose the user $\mathcal{U}$ wants to log in to a relying party $\mathcal{R}\mathcal{P}$ through a specific identity provider $\mathcal{I}\mathcal{D}\mathcal{P}$. Instead of having $\mathcal{R}\mathcal{P}$ directly interact with $\mathcal{I}\mathcal{D}\mathcal{P}$, MISO introduces a mixer $\mathcal{M}$, which first authenticates the user through $\mathcal{I}\mathcal{D}\mathcal{P}$, then informs $\mathcal{R}\mathcal{P}$ of the user’s identity, finishing the SSO workflow.

From $\mathcal{I}\mathcal{D}\mathcal{P}$’s point of view, it only observes that the user is logging in to the mixer—the fact that the user is actually logging in to $\mathcal{R}\mathcal{P}$ is hidden from $\mathcal{I}\mathcal{D}\mathcal{P}$. The mixer can further obfuscate the information obtained from $\mathcal{I}\mathcal{D}\mathcal{P}$ before presenting to $\mathcal{R}\mathcal{P}$, to prevent account linkage across RPs, as well as to allow users to apply arbitrary data redaction, e.g., removing emails returned by Sign in with Google.

Challenges and solutions

Realizing MISO faces two challenges. First, MISO introduces a new entity outside the specification of SSO, which goes against our goal of remaining completely backward compatible with deployed SSO systems. How can we retrofit the mixer $\mathcal{M}$ to the existing SSO architecture in a transparent way? Second, if the mixer $\mathcal{M}$ is adversarial, it could not only track users, but also mount impersonation attacks, i.e., it can log in to $\mathcal{R}\mathcal{P}$ as any user. How do we realize the mixer $\mathcal{M}$ in a trustworthy fashion?

To tackle the first challenge, we run two nested SSO workflows together. The mixer $\mathcal{M}$ acts as an identity provider when interacting with $\mathcal{R}\mathcal{P}$, while as a relying party when interacting with $\mathcal{I}\mathcal{D}\mathcal{P}$. This way, the mixer $\mathcal{M}$ is realized with two roles that are both compatible with existing SSO infrastructures.

To realize a trustworthy mixer $\mathcal{M}$, several options are possible. For example, one could realize the $\mathcal{M}$ with multi-party computation (MPC) so that as long as some fractional of MPC nodes are honest, the adversary (who are limited by the number of MPC nodes he can compromise) cannot track or impersonate users. While theoretically feasible, even state-of-the-art MPC protocols incur orders of magnitude overhead. To achieve practical performance, we realize $\mathcal{M}$ with a Trusted Execution Environment (TEE). To establish secure channels, TEE generates a TLS private key and binds the TEE code to the corresponding public key through remote attestations ^[29]. MISO operates in a trust-upon-first-use model—users (and RPs) verify the attestation the first time they use MISO, after which they can put the verified public key (and the certificate) in their local keychain.

Supporting multiple identity providers

As shown in Figure 1(b), MISO can be naturally generalized to support multiple IdPs in what we call Multi-IdP SSO. This enables a user to protect her third-party application accounts with multiple IdPs (e.g., 2 out of 3 IdPs) to hedge against account compromises or service downtime. On the one hand, even when some IdPs accounts are compromised, the attacker still can not impersonate her to log in to the RP. On the other hand, when some IdPs are unavailable (e.g., due to service downtime), the user can still access her account.

Implementation and evaluation

To demonstrate the practicality of MISO, we implement a prototype of MISO with the Intel Software Guard Extensions (SGX), a widely available TEE. Note that MISO is not specific to Intel SGX in any way and can be realized with any TEEs. We deploy the prototype of MISO on a server with 30GB memory and Intel SGX hardware. We evaluate its performance under concurrent user login requests. Under 200 users/second concurrent login requests, it takes 454ms to finish the standard SSO login on average, and 773ms for the 2-of-3 Multi-IdP SSO. We also compare the performance with a baseline (insecure) implementation without SGX on the same hardware. Our results suggest that average latency of the standard MISO is 2.19× over the basic SSO, and the overhead introduced by SGX is no more than 15%. The evaluation suggests that our prototype achieves practical performance.

Contributions and road map

In summary, our main technical contributions are:

1. MISO. We are the first to design a legacy-compatible privacy-preserving SSO system. Our system guarantees account unlinkability w.r.t. both the IdP and RPs, and allows users to selectively disclose user identity, while remaining completely compatible with existing SSO identity providers. We present the design of MISO and the SSO workflow in § 4, along with a full protocol specification.
2. Multi-IdP SSO. MISO enables the user to sign-on with multiple IdPs in a single SSO workflow. This enables users to leverage multiple IdPs to hedge against single-point failures of account security and availability. This feature can also be used to create decentralized identifiers (DIDs) ^[30] from multiple providers. We specify the Multi-IdP SSO workflow in § C.
3. Prototype implementation and evaluation. We implement a prototype of MISO and evaluate its performance with concurrent user requests. We also compare the prototype with an (insecure) baseline without TEE. Evaluation of the prototype suggests that MISO achieves practical performance, with a latency about 2× over the basic SSO. Implementation and evaluation results are given in § 6.

In what follows, we provide backgrounds on OAuth 2.0 and TEE in § 2, adversary model and design goals in § 3. We present security analysis in § 5. We discuss extended topics in § 7. Finally, we summarize and review related works in § 8 and conclude our work in § 9.

2.   Background

In this section, we provide the background on the basic properties of SSO authentication, the OAuth 2.0 framework, and TEEs.

2.1. Properties of SSO

The key properties for a common SSO solution are:

• User identification at the RP. The result of an instance of SSO is that the RP can get a unique identifier of the user.
• User authentication only at the IdP. In each SSO login instance, the user only authenticates with an IdP once. In particular, the user do not need to authenticate for each RP, or to create and keep any credentials or keys.
• User identity attributes retrieval. The RP is able to obtain the user’s identity attributes confirmed and issued by the IdP.

2.2. OAuth 2.0

Multiple SSO standards and protocols have been deployed over the years, such as SAML ^[31], OpenID ^[32], OAuth 2.0 ^[4],[5] and OpenID Connect (OIDC) ^[18],[27]. Published in 2012, the OAuth 2.0 has become one of the most prominent SSO protocol frameworks. OAuth 2.0 allows the RP to retrieve the user’s protected resources with restrictions from the IdP, and it can be used for SSO if the IdP returns the user’s identity attributes to convince the RP of her identity. OAuth 2.0 is also a basis for a widely adopted SSO protocol, OIDC, which adds a simple identity layer over OAuth 2.0. In most circumstances, an IdP that supports OIDC is also compatible with OAuth 2.0, e.g., Google’s "Sign in with Google" solution ^[20].

Figure 2:Figure 2: The OAuth 2.0 abstract workflow.

As shown in Figure 2, OAuth 2.0 is a three-party protocol involving RP, IdP, and the user. In short, RP initiates the workflow and lets the user authenticate at IdP. Then, RP obtains the grant (code) and token from IdP. Finally, RP obtains the user’s identity attributes with the token. For page limitations, we defer the details to § A. Readers are encouraged to consult since our design utilizes the OAuth 2.0 protocol as its building block. Though the paper itself is self-contained.

2.3. TEE and Intel SGX

A trusted execution environment (TEE) offers a secure execution environment that guarantees confidentiality and integrity of the code and data loaded and executed inside it. TEE can be used to run secure applications inside on an untrusted environment (e.g., a host).

Intel Software Guard Extensions (SGX) ^[33]–^[37] is an extension of the x86 instruction set architecture, which offers hardware-based memory encryption that isolates specific user-level application code and data in memory. SGX allows applications to create isolated memory regions for code and data (called enclaves ) to protect them from potential malicious privileged software ^[38], operating system, hypervisor code, or even some hardware attacks ^[39] on the same host. Code and data inside the enclave are protected in a space of memory pages called enclave page caches (EPC) and encrypted by the memory encryption engine (MEE) to prevent access outside the enclave. The main protective technologies of SGX include: runtime isolation (enclave), ecall/ocall interfaces, attestation, and sealing, readers may refer to ^[34] for a more in-depth exposition.

3.   Adversarial Model and Design Goals

In this section, we begin with the adversarial model and assumptions. Then we state the privacy goals along with other desired properties that MISO enjoys.

3.1. Adversarial Model

According to Figure 1, there are four parties in MISO: the IdP, the RP, the user, and the mixer. Since our system is web-based, the user uses a user-agent that can perform actions on her behalf. We consider the following adversarial model:

Honest-but-curious IdP

The IdP is honest, which means it is implemented correctly and follows the standard OAuth 2.0 protocol. But a curious IdP is interested in collecting the user information throughout the execution of the protocol, e.g., tracking the user’s login activities among RPs.

Malicious RPs

The RPs may intentionally deviate from the protocol to investigate interactions between other parties. The adversary can control a group of RPs to break the privacy guarantees. We only consider that the group of malicious RPs can only make use of information leaked from the protocol, e.g., they can not make use of users’ network connection information.

Users

Users can be honest or malicious. Malicious users can collude with the RPs. For instance, malicious users and RPs may work together to impersonate victim users in order to log in to other honest RPs. We assume an honest user deploys a secure user-agent, commonly a modern web browser, which is supposed to safeguard its user’s local credentials, e.g., her password on the IdP. Also, an honest user never allows distinctive identity attributes (personally identifiable information ^[40]) that can be easily correlated to her, e.g., telephone number, or email address, to be shared. So that unlinkability is possible across the RPs.

Malicious mixer host

The mixer is implemented in a TEE. The adversary could compromise the host of the mixer by exploiting software vulnerabilities, and attempt to steal system secrets. We use Intel SGX in particular for implementation, and we assume the enclave achieves integrity and confidentiality guarantees as defined in ^[34],[41].

Correct OAuth 2.0 implementation

Care must be taken to implement and configure OAuth 2.0 correctly. We refer readers to ^[42]–^[44] for a survey of OAuth 2.0 implementation pitfalls. MISO is built on top of up-to-date OAuth 2.0 implementation and we assume the implementation is free of known OAuth 2.0 protocol-level vulnerabilities.

Denial-of-Service (DoS) attacks are out of scope.

3.2. Design Goals

Privacy goals

We aim to achieve the following privacy goals (formal privacy definitions will be given in § 5.1):

• IdP Unlinkability (Definition 1). Informally, given two RPs RP ₁ and RP ₂ and a user who logs in to one of them through an IdP, IdP unlinkability requires that the IdP cannot decide which RP the user logged in to. The definition generalizes the multiple RPs naturally.
• RP Unlinkability (Definition 2). This definition captures the requirement that a group of RPs cannot trace user login activities. More precisely, given two users U ₁ and U ₂, when one of them logs in at a given RP, that RP cannot decide which user logged in, even through colluding with other RPs to which U ₁ and U ₂ have previously logged in. Note that in existing SSO protocols, RPs learn users’ unique identifiers from the IdP, and thus can break this property.
• Collusive-IdP-RP Unlinkability (Definition 3). IdP unlinkability and RP unlinkability should hold even when the IdP colludes with RPs and reveals users’ unique identifiers to them before users log in. (However, if the IdP and RPs collude while a user logs in, they can potentially identify users through timing side channels. Time-based attack is out of the scope of this paper and existing works ^[23],[25].)

Selective disclosure of user identity

The user is given the ability to only disclose her pre-selected identity attributes that he or she wished to share with the RP. The user is supposed to hide her distinctive identity attributes such as email address and phone number to prevent account linkage across RPs in order to achieve full-scale privacy protection. With the assumption that there is no leakage outside the protocol, our protocol aims to allow the user to log in at the RP anonymously , by revealing none of her identity attributes to the RP.

Security requirements for the mixer

Given an SSO instance, the mixer should not learn the identity of the involved user (note that the mixer can identify RPs and IdPs through their TLS public keys) nor can it impersonate the user on the RP.

Legacy-compatibility with OAuth 2.0

An IdP that supports OAuth 2.0 should be applied to our protocol without any modification. Also, RP only needs to present a button on its login page for initiating our protocol and perform the attestation check of the mixer upon the first use. There are no special scripts or keys for the IdP and RPs.

This is the highlight feature of MISO that distinguish is from works on cryptography-based privacy-preserving SSO solutions that either design new protocols or make changes to the OAuth 2.0 or OIDC protocol. However, none of them achieve our privacy goals without modifying the OAuth 2.0 protocol of the IdP. Since most commercial off-the-shelf IdPs are implemented over the OAuth 2.0 protocol, e.g., Google, Facebook, and Twitter, asking IdPs to adopt a modified OAuth 2.0 protocol or even an entirely different protocol is neither desirable nor practical.

Robust to single-point failures

Our protocol aims to protect the user against single-point failures w.r.t. security and availability. Security is defined as: the attacker can not impersonate the user to log in to the RP by compromising some of her accounts on the IdPs. Availability is defined as: the user can still log in to her same account on the RP when some of the IdPs are unavailable, e.g., service downtime.

Figure 3:Figure 3: System architecture and the standard SSO workflow for MISO.

4.   MISO

In this section, we present the system design of MISO and specify the SSO workflow (§ 4.2) and the formal MISO protocol (§ 4.3 in message-driven fashion). In MISO architecture, there are four types of parties: user(s) $\mathcal{U}$ (a user’s user-agent $\mathcal{U}\mathcal{A}$ acts on behalf of her), the Relying Party(ies) $\mathcal{R}\mathcal{P}$, the Identity Provider(s) $\mathcal{I}\mathcal{D}\mathcal{P}$, and the mixer $\mathcal{M}$. Our system is designed to provide service for a large population of users and RPs $\mathcal{R}{\mathcal{P}_1}, \cdots ,\mathcal{R}{\mathcal{P}_m}$ and IdPs $\mathcal{I}\mathcal{D}{\mathcal{P}_1}, \cdots ,\mathcal{I}\mathcal{D}{\mathcal{P}_k}$. In general, a user may wish to use our system to sign-on $\mathcal{R}{\mathcal{P}_j}$ with her privacy protected, and she authenticates with a certain $\mathcal{I}\mathcal{D}{\mathcal{P}_i}$, or a group of IdPs $\mathcal{I}\mathcal{D}{\mathcal{P}_1}, \ldots ,\mathcal{I}\mathcal{D}{\mathcal{P}_k}$. In order to achieve privacy protection, $\mathcal{R}{\mathcal{P}_j}$ communicates to the IdP(s) through $\mathcal{M}$ only.

4.1. Overview of MISO

The main strategy of MISO is that we manage all the interactions between $\mathcal{R}\mathcal{P}$ and $\mathcal{I}\mathcal{D}\mathcal{P}$ through a central mixer $\mathcal{M}$, which is implemented with the Trusted Execution Environment (TEE). Figure 3 illustrates the architecture of MISO and the protocol workflow for SSO. At a high-level glance, the mixer $\mathcal{M}$ not only stands in the middle of the system but also breaks the system into two independent yet closely hinged parts. From Figure 3, if we leave $\mathcal{R}\mathcal{P}$ aside and focus on the rest of the system, $\mathcal{M}$, $\mathcal{U}$, and $\mathcal{I}\mathcal{D}\mathcal{P}$ form a standard OAuth 2.0 trio, and the protocol flow is identical to that in Figure 2. And if we leave $\mathcal{U}$ and $\mathcal{I}\mathcal{D}\mathcal{P}$ aside, $\mathcal{R}\mathcal{P}$ and $\mathcal{M}$ make up an OAuth 2.0-like flow except that $\mathcal{M}$ makes the authorization grant on itself without the participation of the user $\mathcal{U}$.

Therefore, the mixer $\mathcal{M}$ in MISO mixes the two nested OAuth 2.0 flows together by playing different roles towards different parties: $\mathcal{M}$ acts the role of a relying party when interacting with $\mathcal{I}\mathcal{D}\mathcal{P}$, and acts the role of an identity provider when interacting with $\mathcal{R}\mathcal{P}$. Thus, from the perspective of $\mathcal{I}\mathcal{D}\mathcal{P}$, the $\mathcal{M}$ is no other than a normal relying party, and $\mathcal{R}\mathcal{P}$ treats $\mathcal{M}$ as if it is a quasi-IdP with only minimal differences. With this design, we are able to reuse the existing OAuth 2.0 protocol as much as possible to achieve the legacy-(OAuth 2.0)-compatibility.

The mixer $\mathcal{M}$ are required to be fully trusted, and keep the confidentiality and integrity of its code and data. MISO leverages TEE to realize the functionality of $\mathcal{M}$. The mixer $\mathcal{M}$ is a TLS server started in a TEE on a host. The user $\mathcal{U}$ and $\mathcal{R}\mathcal{P}$ use remote attestation to make sure that it is indeed communicating with $\mathcal{M}$ secured by a TEE, initialized properly in the enclave. Data inside $\mathcal{M}$ is inaccessible outside the enclave on the same host due to runtime isolation. Because of this, $\mathcal{M}$ can keep the secrets and keys privately. The sealing feature assures persistent storage for important credentials, so even if the mixer is down, long-term secrets sealed previously can be revived when the enclave restarts. In conclusion, we use TEE to ensure the trustworthiness of $\mathcal{M}$, which is the key to addressing our privacy threats stated.

Notation

In this and upcoming sections, we use letters in typewriter font, e.g., para, to denote the parameters passed through the protocol. Note that unless we mention that a parameter is optional, it is treated as a MUST field. Other keywords ahead of a parameter are to be interpreted as described in RFC 2119 ^[45]. We use different subscripts (A_mixer, A_RP, and A_IdP) to distinguish a similar type of parameters A that belong to different parties. E.g., token_mixer is the access token held by the mixer and token_RP is the access token held by the RP. Similarly, we use the underscores (B_mixer and B_IdP) to distinguish a similar type of protocol endpoints or URIs B.

4.2. MISO Workflow

Standard MISO workflow consists of three parts, Mixer registration , RP registration , and login flow. The two registration parts are the preparation processes before the login flow. Before registration, $\mathcal{M}$ samples a 256bit PRF key ${\text{sk}}_{{\text{TEE }}}^{{\text{PRF }}}$ and seals it to the disk. $\mathcal{U}$ and $\mathcal{R}\mathcal{P}$ need to verify the remote attestation of $\mathcal{M}$ if this is their first time using MISO. Attestation gives proof that the TEE is indeed executing the presumed code (the $\mathcal{M}$ code shall be open-sourced for public review). Also, prior to the login flow, the user $\mathcal{U}$ is supposed to set her preferences of selective-disclosure on the mixer $\mathcal{M}$ through a trusted channel such as submitting an HTTPS form, otherwise by default $\mathcal{M}$ will disclose none of her attributes to $\mathcal{R}\mathcal{P}$, except a blinded user identifier. Figure 3 illustrates the workflow (login flow).

Mixer registration

The mixer $\mathcal{M}$ registers with $\mathcal{I}\mathcal{D}\mathcal{P}$ as an OAuth 2.0 relying party, i.e., acts as a relying party from $\mathcal{I}\mathcal{D}\mathcal{P}$’s perspective. The parameters below are the same as that in the OAuth 2.0 standard. $\mathcal{M}$ provides its redirect URI uri_mixer and other required information depending on the certain specification of $\mathcal{I}\mathcal{D}\mathcal{P}$, and gets its credentials, the client identifier cid_mixer and the client secret csec_mixer from $\mathcal{I}\mathcal{D}\mathcal{P}$. In this workflow, $\mathcal{M}$ needs to register at all the identity providers which it wishes to support, and saves its credentials in persistent storage for future use ($\mathcal{M}$ actually uses private keys generated in TEE to seal data inside the TEE to the encrypted disk).

RP registration

$\mathcal{R}\mathcal{P}$ registers with $\mathcal{M}$. This is almost identical to the RP registration in OAuth 2.0 except $\mathcal{R}\mathcal{P}$ registers with $\mathcal{M}$ instead of $\mathcal{I}\mathcal{D}\mathcal{P}$. This time, $\mathcal{M}$ acts as an identity provider from the $\mathcal{R}\mathcal{P}$’s perspective. $\mathcal{R}\mathcal{P}$ must submit its redirect URI uri_RP to get its credentials, the client identifier cid_RP, and the client secret csec_RP from $\mathcal{M}$. For each RP that participates in this workflow, it only needs to register with $\mathcal{M}$ once. $\mathcal{M}$ saves the client credentials of $\mathcal{R}\mathcal{P}$ securely for future authentication, and the redirect URI uri_RP with the corresponding $\mathcal{R}\mathcal{P}$’s client credentials.

Login flow

This workflow is constructed from two OAuth 2.0 authorization code grant flows. Hence, we denote the OAuth 2.0 flow which consists of $\mathcal{R}\mathcal{P}$, $\mathcal{M}$ as the outer OAuth 2.0 ¹ since both the beginning and the finishing steps of the login flow are contained in this OAuth 2.0 flow. Similarly, we denote the workflow which consists of $\mathcal{M}$, $\mathcal{I}\mathcal{D}\mathcal{P}$, and $\mathcal{U}$ as the inner OAuth 2.0 , as this flow is executed in the middle of the login flow. $\mathcal{M}$ has three protocol endpoints to serve resources to $\mathcal{R}\mathcal{P}$:

• Authorization endpoint ( /auth_mixer). This is used by $\mathcal{R}\mathcal{P}$ to obtain the authorization code code_RP from $\mathcal{M}$, via user-agent $\mathcal{U}\mathcal{A}$’s redirection.
• Token endpoint ( /token_mixer). This is used by $\mathcal{R}\mathcal{P}$ to exchange the authorization code code_RP for the access token token_RP, after $\mathcal{R}\mathcal{P}$ authenticates with $\mathcal{M}$ successfully with its credentials cid_RP, csec_RP.
• Resource endpoint ²( /res_mixer). This is used by $\mathcal{R}\mathcal{P}$ to retrieve user $\mathcal{U}$’s identity attributes from $\mathcal{M}$ with its access token.

$\mathcal{I}\mathcal{D}\mathcal{P}$ also owns three protocol endpoints to offer similar services but to $\mathcal{M}$, we denote them with /auth_IdP, /token_IdP, and /res_IdP. The usages, forms, and specifications of the authorization codes code_RP, code_mixer, and the access tokens token_RP, token_mixer follow their descriptions in the OAuth 2.0 framework, readers may refer to § A.3 for a brief overview, but beware that the code_RP is issued from $\mathcal{M}$ to $\mathcal{R}\mathcal{P}$ and the code_mixer is issued from $\mathcal{I}\mathcal{D}\mathcal{P}$ to $\mathcal{M}$, same interpretations for the access tokens.

The login flow has a sandwich -like structure, both logically and chronologically. It begins with the outer OAuth 2.0 workflow, then steps into the inner OAuth 2.0, and returns to the outer OAuth 2.0 again when the inner workflow finishes. Before $\mathcal{R}\mathcal{P}$ initiates the login flow, the user $\mathcal{U}$’s user-agent $\mathcal{U}\mathcal{A}$ loads the login page of $\mathcal{R}\mathcal{P}$.

We specify the login flow as follows, the indexing of the steps is consistent with that in Figure 3:

1. $\left( {\mathcal{R}\mathcal{P}\xrightarrow{{\mathcal{U}\mathcal{A}}}\mathcal{M}} \right)$ This is $\mathcal{R}\mathcal{P}$’s authorization request: $\mathcal{R}\mathcal{P}$ initiates the flow by directing $\mathcal{U}$’s user-agent $\mathcal{U}\mathcal{A}$ to $\mathcal{M}$’s authorization endpoint /auth_mixer with its client identifier cid_RP, a local state state_RP (a random generated nonce to prevent CSRF attacks) and the redirect URI uri_RP to which $\mathcal{M}$ will redirect $\mathcal{U}\mathcal{A}$ back later after the inner OAuth 2.0 workflow ends.
2. $\left( {\mathcal{M}\xrightarrow{{\mathcal{U}\mathcal{A}}}\mathcal{I}\mathcal{D}\mathcal{P}} \right)$ This is $\mathcal{M}$’s authorization request. After $\mathcal{M}$ checks that the client identifier cid_RP and redirect URI uri_RP are consistent with those $\mathcal{R}\mathcal{P}$ got issued in the RP registration step, $\mathcal{M}$ then directs $\mathcal{U}\mathcal{A}$ to the $\mathcal{I}\mathcal{D}\mathcal{P}$’s authorization endpoint /auth_IdP with its client identifier cid_mixer, a local state state_mixer and the redirect URI uri_mixer for the future redirection to $\mathcal{M}$. $\mathcal{I}\mathcal{D}\mathcal{P}$ authenticates $\mathcal{U}$ via $\mathcal{U}\mathcal{A}$, e.g., by checking $\mathcal{U}$’s account and password on $\mathcal{I}\mathcal{D}\mathcal{P}$, and then establishes whether $\mathcal{U}$ grants or denies the authorization request (made by $\mathcal{R}\mathcal{P}$ and transmitted by $\mathcal{M}$) via a consent window. If $\mathcal{U}$ denies, the flow terminates. If $\mathcal{U}$ grants, the flow goes on.
3. $\left( {\mathcal{I}\mathcal{D}\mathcal{P}\xrightarrow{{\mathcal{U}\mathcal{A}}}\mathcal{M}} \right)$ Assuming $\mathcal{U}$ grants the request, $\mathcal{I}\mathcal{D}\mathcal{P}$ redirects $\mathcal{U}\mathcal{A}$ back to $\mathcal{M}$ with its redirect URI uri_mixer provided earlier. The redirection includes the authorization code code_mixer and any local state state_mixer passed by $\mathcal{M}$ earlier.
4. $\left( {\mathcal{M} \to \mathcal{I}\mathcal{D}\mathcal{P}} \right)\mathcal{M}$ requests the access token token_mixer from $\mathcal{I}\mathcal{D}\mathcal{P}$’s token endpoint /token_IdP by including the authorization code code_mixer received in the previous step. When making the request, $\mathcal{M}$ authenticates with $\mathcal{I}\mathcal{D}\mathcal{P}$ using the cid_mixer and csec_mixer. The redirect URI uri_mixer used to obtain the authorization code code_mixer should also be included for verification.
5. $\left( {\mathcal{I}\mathcal{D}\mathcal{P} \to \mathcal{M}} \right)$$\mathcal{I}\mathcal{D}\mathcal{P}$ authenticates $\mathcal{M}$ and validates its authorization code code_mixer, and ensures that the redirect URI uri_mixer received matches the URI used for redirection. If valid, $\mathcal{I}\mathcal{D}\mathcal{P}$ responds with the access token token_mixer.
6. $\left( {\mathcal{M} \to \mathcal{I}\mathcal{D}\mathcal{P}} \right)\mathcal{M}$ uses its access token token_mixer to retrieve $\mathcal{U}$’s unique user identifier uid and other user attributes from $\mathcal{I}\mathcal{D}\mathcal{P}$’s resource endpoint /res_IdP. The user identifier uid is unique among all users on the certain IdP and shall never be reused.
7. $\left( {\mathcal{I}\mathcal{D}\mathcal{P} \to \mathcal{M}} \right)$$\mathcal{I}\mathcal{D}\mathcal{P}$ returns the uid along with other attributes. If $\mathcal{U}$ has selected to disclose any attributes previously, $\mathcal{M}$ keeps these attributes. $\mathcal{M}$ calculates a pre -blinded user identifier, dubbed preUID: $$\begin{equation*}\operatorname{preUID} : = \operatorname{PRF} \left( {{\text{sk}}_{{\text{TEE}}}^{{\text{PRF}}}} \right.,{\text{uid}}\left. {{\text{||ci}}{{\text{d}}_{{\text{RP}}}}} \right)\end{equation*}$$
8. $\mathcal{M}$ generates a per-user salt s and saved to the encrypted disk in a table (preUID, s). preUID is used as the query of the per-user salt. Finally, $\mathcal{M}$ calculates the blinded user identifier UID: $$\begin{equation*}{\text{UID}}: = \operatorname{PRF} \left( {{\text{sk}}_{{\text{TEE}}}^{{\text{PRF}}},{\text{uid}}\left\| {{\text{ci}}{{\text{d}}_{{\text{RP}}}}} \right\|{\text{s}}} \right)\end{equation*}$$
9. The UID is the only user identifier that is passed to $\mathcal{R}\mathcal{P}$ for recognizing $\mathcal{U}$.
10. $\left( {\mathcal{M}\xrightarrow{{\mathcal{U}\mathcal{A}}}\mathcal{R}\mathcal{P}} \right)$ If the inner OAuth 2.0 flow succeeds, $\mathcal{M}$ redirects $\mathcal{U}\mathcal{A}$ back to $\mathcal{R}\mathcal{P}$ with its redirect URI uri_RP provided earlier. The redirection includes the authorization code code_RP and any local state state_RP passed by $\mathcal{R}\mathcal{P}$ earlier.
11. $\left( {\mathcal{R}\mathcal{P} \to \mathcal{M}} \right)\mathcal{R}\mathcal{P}$ requests the access token token_RP from $\mathcal{M}$’s token endpoint /token_mixer by including the authorization code code_RP received in the previous step. When making the request, $\mathcal{R}\mathcal{P}$ authenticates with $\mathcal{M}$ using the cid_RP and csec_RP. The redirect URI uri_RP used to obtain the authorization code code_RP should also be included for verification.
12. $\left( {\mathcal{M} \to \mathcal{R}\mathcal{P}} \right)\mathcal{M}$ authenticates $\mathcal{R}\mathcal{P}$ and validates its authorization code code_RP, and ensures that the redirect URI uri_RP received matches the URI used for redirection. If valid, $\mathcal{M}$ responds with the access token token_RP.
13. $\left( {\mathcal{R}\mathcal{P} \to \mathcal{M}} \right)\mathcal{R}\mathcal{P}$ uses its access token token_RP to retrieve $\mathcal{U}$’s UID from $\mathcal{M}$’s resource endpoint /res_mixer. $\mathcal{R}\mathcal{P}$ can also use the token_RP to retrieve the attributes $\mathcal{U}$ has already selected to disclose.
14. $\left( {\mathcal{M} \to \mathcal{R}\mathcal{P}} \right)\mathcal{M}$ returns UID along with other attributes (if any).

The result of the successful execution of the login flow is that UID $\mathcal{R}\mathcal{P}$ obtains the user $\mathcal{U}$’s unique user identifier from $\mathcal{M}$. $\mathcal{R}\mathcal{P}$ is supposed to keep a list of unique user identifiers UIDs for a certain $\mathcal{I}\mathcal{D}\mathcal{P}$. Once the UID it received is off the list, it should create a new profile for $\mathcal{U}$ and add it to the list. Next time, $\mathcal{U}$ will be authenticated successfully if $\mathcal{R}\mathcal{P}$ gets the same UID again.

4.3. MISO Protocol

We formally specify the MISO protocol in Figure 4. To formalize the attested execution model of TEE, we adopt the ideal functionality ${\mathcal{G}_{{\text{att }}}}$ proposed by Pass et al. ^[46]. We can model TEE’s group signature as a regular signature scheme Σ_TEE, which contains a pair of public and secret keys, and denoted pk_TEE and sk_TEE. In an attested execution on the TEE, a party first send a user-defined program prog inside a new enclave, dubbed the "install" call. Upon installation, ${\mathcal{G}_{{\text{att }}}}$ generates an enclave and returns eid, the enclave identifier that can be used to identify the enclave instance. Upon a "resume" call with the eid, ${\mathcal{G}_{{\text{att }}}}$ executes the program prog over the inputs inp, obtaining an output outp and a signature ${\sigma _{{\text{TEE }}}} = \sum\nolimits_{{\text{TEE}}} \cdot \operatorname{Sig} \left( {{\text{s}}{{\text{k}}_{{\text{TEE}}}},\left( {{\text{prog,outp}}} \right)} \right)\left( {{\text{s}}{{\text{k}}_{{\text{TEE}}}} = {\mathcal{G}_{{\text{att}}}} \cdot \operatorname{getsk} ()} \right)$. The signature σ _TEE is the resulting attestation of the enclave. To verify an attestation, the verifier party need to use pk_TEE, which can be obtained with ${\mathcal{G}_{{\text{att }}}}{\text{getpk}}()$.

The MISO protocol specification is presented in Prot _MISO (Figure 4) (supplementary protocols are given in § B). The protocol relies on TEE’s ideal functionality ${\mathcal{G}_{{\text{att }}}}$. Readers can combine Prot _MISO with Figure 3 and § 4.2 for a clearer comprehension.

4.4. Transitioning to Multi-IdP SSO

The MISO architecture shows its strong capabilities in building complex authentication schemes. We demonstrate its potential with the Multi-IdP SSO workflow, under the extended setting of multiple IdPs. Similar to the concept of multi-signature, which allows several private keys to jointly generate a single signature, the Multi-IdP SSO workflow allows users to use identities from multiple IdPs to log in to a single RP. Also, our workflow supports 2-of-3 schemes. Details of the extended version of MISO is deferred to § C.

5.   Security Analysis

5.1. Security and Privacy Properties

Under the assumptions outlined in § 3.1, we will show that MISO satisfies the security and privacy goals outlined in § 3.2. At a high level, the security and privacy of MISO boils down to that of TLS and TEE. The mixer starts a TLS server in a TEE. Upon initialization, it will generate a pair of TLS keys, publish the public key with an attestation proving its correctness (e.g., as done in ^[47],[48]) while keeping the secret key in the enclave. The user (via the user-agent) verifies the remote attestation in a trust-upon-first-use manner to verify that the given TLS public key is securely generated by a TEE so that the corresponding secret key is kept secret. Then, the user can establish a secure channel with the mixer TEE. Using TLS ensures that the mixer host cannot learn user identities other than the IP addresses. In Table 1, we list the information learned by each party in MISO and the standard SSO protocol.

Unlinkability. We will prove that MISO not only achieves IdP unlinkability and RP unlinkability, but also maintains unlinkability even in the case of collusion between IdP and RPs.

Definition 1 (IdP Unlinkability). MISO offers IdP unlinkability if, for any stateful PPT adversary $\mathcal{A}$, $\Pr \left[ {\operatorname{G} _{{\text{MISO,}}\mathcal{I}\mathcal{D}\mathcal{P}{\text{ }}}^{unlink{\text{ }}}(\lambda ,\mathcal{A}) \Rightarrow 1} \right] \leq \frac{1}{2} + \operatorname{negl} (\lambda )$. Figure 5 specifies the game ${\text{G}}_{{\text{MISO}},\mathcal{I}\mathcal{D}\mathcal{P}}^{unlink}$, in which the adversary $\mathcal{A}$ is the honest-but-curious IdP. The challenger simulates an user U and registers U with the IdP, allowing $\mathcal{A}$ to learn U ’s uid. Next, the challenger simulates two RPs RP ₀ and RP ₁, and registers them at the mixer (specifically the enclave ${\mathcal{G}_{{\text{att }}}}$[prog]). The challenger picks a random bit b ∈ {0, 1} and simulate the login flow with $\mathcal{I}\mathcal{D}\mathcal{P}$ and RP_b. The adversary must guess which RP is picked.

Figure 4:Figure 4: The MISO protocol

Figure 5:Figure 5: IdP unlinkability game.

Figure 6:Figure 6: RP unlinkability game.

Figure 7:Figure 7: Collusive-IdP-RP unlinkability game.

Definition 2 (RP Unlinkability). MISO offers RP unlinkability if, for any stateful PPT adversary $\mathcal{A}$, $\Pr \left[ {{\text{G}}_{{\text{MISO}},\mathcal{R}\mathcal{P}}^{unlink{\text{ }}}(\lambda ,\mathcal{A}) \Rightarrow 1} \right] \leq \frac{1}{2} + \operatorname{negl} (\lambda )$. Figure 6 specifies the game ${\text{G}}_{{\text{MISO}},\mathcal{R}\mathcal{P}}^{unlink{\text{ }}}$, in which the adversary controls two RPs, RP ₀ and RP ₁. The challenger simulates two users U ₀ and U ₁ and logs U ₀ and U ₁ in to RP ₀, allowing $\mathcal{A}$ to learn U ₀ and U ₁’s UID_0,0 and UID_0,1 on RP ₀. Then, the challenger randomly picks a user U_b to login RP ₁, and the adversary must guess which user is picked.

Definition 3 (Collusive-IdP-RP Unlinkability). MISO offers collusive-IdP-RP unlinkability if, for any stateful PPT adversary $\mathcal{A}$, $\Pr \left[ {{\text{G}}_{{\text{MISO}}}^{unlink}(\lambda ,\mathcal{A}) \Rightarrow 1} \right] \leq \frac{1}{2} + \operatorname{negl} (\lambda )$. Figure 7 specifies the game ${\text{G}}_{{\text{MISO}}}^{unlink}$, in which the adversary controls two RPs, RP ₀ and RP ₁, and can get uids of the users on the IdP. The challenger simulates two users U ₀ and U ₁, and registers them with the IdP, allowing $\mathcal{A}$ to learn the uid₀ and uid₁ of U ₀ and U ₁. Subsequently, the challenger enables both U ₀ and U ₁ to log in to RP ₀ using the prescribed Prot _MISO. Then, the challenger randomly picks a user U_b to login RP ₁, and the adversary must guess which user is picked.

Note that compared to Definition 2, $\mathcal{A}$ learns not only UID_i,j but also uid_j for each RP_i and user U_j.

We note that IdP unlinkability and RP unlinkability are weaker guarantees than collusive-IdP-RP unlinkability. IdP unlinkability specifies that the IdP cannot determine if a user has logged into an RP, while RP unlinkability specifies that given a UID on the RP, the RP cannot determine if a user has logged in or not. The definition of collusive-IdP-RP expresses the infeasibility of collusive IdP and RPs to determine whether a user logs in an RP or not. We prove that MISO guarantees collusive-IdP-RP unlinkability as follows.

Proof. The confidentiality provided by TEE guarantees that the adversary cannot get the PRF key $\left( {{\text{sk}}_{{\text{TEE}}}^{{\text{PRF}}}} \right)$.

In the setup phase, according to the power of adversary specified in the ${\text{G}}_{{\text{MISO}}}^{unlink{\text{ }}}$, the adversary $\mathcal{A}$ can obtain uid₀ and uid₁ of U ₀ and U ₁, cid_RP0 and cid_RP1 of RP ₀ and RP ₁, as well as the UID_0,0 and UID_0,1 subsequent to the users’ login to RP ₀. Then, upon U_b logging into RP ₁, the adversary $\mathcal{A}$ can acquire UID_1,b.

According to the Prot _MISO (line #62), UID_1,b is calculated from $\operatorname{PRF} \left( {{\text{sk}}_{{\text{TEE}}}^{{\text{PRF}}},{\text{ui}}{{\text{d}}_b}\left\| {{\text{ci}}{{\text{d}}_{{\text{RP}}1}}} \right\|{\text{s}}} \right)$. To prove the unlinkability in MISO, it is equivalent to prove that, given uid_i and UID_0,i for i ∈ {0, 1} and UID_1,b, the adversary $\mathcal{A}$ cannot determine b.

We prove this using a hybrid argument. Initially, suppose there is a $\mathcal{M}'$ that substitutes the PRF with a random function (the resulting system is denoted as MISO′ ). If UID_1,b is computed from uid_b by a random function, then the probability of $\mathcal{A}$ winning the game is equivalent to bit guessing, i.e., $\Pr \left[ {{\text{G}}_{{\text{MIS}}{{\text{O}}^\prime }}^{unlink}(\lambda ,\mathcal{A}) \Rightarrow 1} \right] = \frac{1}{2}$.

Next, we will show that $\mathcal{A}$ cannot distinguish ${\text{G}}_{{\text{MISO }}}^{unlink{\text{ }}}$ and ${\text{G}}_{{\text{MISO}}{{\text{ }}^\prime }}^{unlink{\text{ }}}$. If $\mathcal{A}$ can distinguish between ${\text{G}}_{{\text{MISO }}}^{unlink{\text{ }}}$ and ${\text{G}}_{{\text{MISO}}{{\text{ }}^\prime }}^{unlink{\text{ }}}$ with an advantage $\operatorname{Adv} (\lambda ) = \left| {\Pr \left[ {{\text{G}}_{{\text{MISO}}}^{unlink{\text{ }}} \Rightarrow 1} \right] - \Pr \left[ {{\text{G}}_{{\text{MIS}}{{\text{O}}^\prime }}^{unlink{\text{ }}} \Rightarrow 1} \right]} \right|$, we can construct an adversary $\mathcal{B}$ with the same advantage to win the PRF game ^[49] (see Figure 13) by following: $\mathcal{B}$ submits a sequence of queries in the form of x_i := uid_i|| cid_RP||s (i = 1, 2, ⋯ ) to the challenger. The challenger randomly selects a function f to computes y_i ← f (x_i ), which will then be provided to $\mathcal{B}$. Subsequently, $\mathcal{B}$ will forward the sequence of results y_i to $\mathcal{A}$ and pass each y_i off as UID_i. Finally, $\mathcal{B}$ will provide the output of $\mathcal{A}$ to the challenger as its own output.

Let W_b be the event that $\mathcal{B}$ outputs 1 in the PRF game for b ∈ {0, 1}, the advantage of $\mathcal{B}$ is $\operatorname{Adv} _{\mathcal{B}}^{{\text{PRF}}}(\lambda ) = \left| {\Pr \left[ {{W_0}} \right] - \Pr \left[ {{W_1}} \right]} \right|$ . The reduction (see Figure 14) shows $\Pr \left[ {{W_0}} \right] = \Pr \left[ {{\text{G}}_{{\text{MlSO }}}^{unlink{\text{ }}} \Rightarrow 1} \right]$ and $\Pr \left[ {{W_1}} \right] = \Pr \left[ {{\text{G}}_{{\text{MIS}}{{\text{O}}^\prime }}^{unlink{\text{ }}} \Rightarrow 1} \right]$. $\operatorname{Adv} _{\mathcal{B}}^{\operatorname{PRF} }(\lambda ) = \left| {\Pr \left[ {{W_0}} \right] - \Pr \left[ {{W_1}} \right]} \right| = \left| {\Pr \left[ {{\text{G}}_{{\text{MlSO}}}^{unlink{\text{ }}} \Rightarrow 1} \right] - \Pr \left[ {{\text{G}}_{{\text{MlS}}{{\text{O}}^\prime }}^{unlink{\text{ }}} \Rightarrow 1} \right]} \right| = \operatorname{Adv} (\lambda )$. Thus, we have successfully created an adversary $\mathcal{B}$ who can win the PRF game with Adv(λ ). This implies that $\mathcal{A}$ cannot distinguish between ${\text{G}}_{{\text{MISO }}}^{unlink{\text{ }}}$ and ${\text{G}}_{{\text{MISO}}{{\text{ }}^\prime }}^{unlink{\text{ }}}$, except for a negligible probability. Given that $\Pr \left[ {{\text{G}}_{{\text{MIS}}{{\text{O}}^\prime }}^{unlink{\text{ }}}(\lambda ,\mathcal{A}) \Rightarrow 1} \right] = \frac{1}{2}$, we have $\Pr \left[ {{\text{G}}_{{\text{MISO}}}^{unlink}(\lambda ,\mathcal{A}) \Rightarrow 1} \right] \leq \frac{1}{2} + {\text{negl}}\left( \lambda \right)$. □

As per our proof, MISO not only guarantees collusive-IdP-RP unlinkability but also IdP unlinkability and RP unlinkability.

Selective disclosure

This property follows immediately from the integrity and confidentiality of TEEs. In MISO, users specify the scope of information to be given to an RP. The mixer will enforce the specification (integrity) and intercept and drop data that users wish to keep secret (confidentiality).

Security of the mixer

Due to the confidentiality guarantee of TEEs and the security of TLS, the mixer (the malicious host) cannot infer the identity of the user from encrypted traffic. (We assume users connect to the mixer via anonymity network to hide network-level identities.) Due to the integrity of TEEs, the mixer will only emit a token to RP after successfully authenticating the user with the IdP, thus the mixer cannot impersonate users.

5.2. Tolerating Side-channel Leakage

TEEs are well-known to be subject to side-channel leakage ^[50]–^[53] that can break confidentiality. We take three measures to mitigate the impact of potential side channels, in addition to standard measures such as using constant-time cryptography implementation.

Using salt to slow down rainbow-table attacks

In the case of TEE compromise, the PRF key ${\text{sk}}_{{\text{TEE}}}^{{\text{PRF}}}$ will be leaked. Then, if a strong adversary choose to collude with the malicious RP, he could launch rainbow-table attacks ^[54],[55] to recover uid from the blinded UID. We slow down such attacks by constructing UID with a per-user salt (both in basic protocol and Multi-IdP SSO). The salt table is also kept in the same disk with ${\text{sk}}_{{\text{TEE}}}^{{\text{PRF}}}$. Even if the salts are leaked, the adversary has to mount attacks by constructing per-salt rainbow-tables, which significantly slows down the attack.

Keeping secrets short-lived

Secret values such as the access tokens obtained from IdPs (token_mixer) only reside in the memory for a short period of time, and we remove them from the memory as soon as the SSO protocol concludes. With this token, the attacker can query the IdP for private user information (up to the scope set by the user when authenticating to the IdP). However, by keeping secrets short-lived, they are less likely to be leaked through side-channel attacks (though that is not guaranteed).

Rotating long-term secrets

Some secrets live in the memory for a relatively long period of time, with the most crucial one being the TLS key. If the attacker can obtain the TLS key, then she can decrypt the traffic and forge messages, and all bets are off. To combat, one can frequently rotate the TLS key, which however requires users and RPs to verify attestations each time. A better approach is to leverage hierarchical attestation ^[56] by running the attestation verification logic in another TEE TEE_verify. This way, users and RPs only need to verify one attestation produced by TEE_verify (which establishes the public key of TEE_verify), after which they can accept any public key signed by TEE_verify with regular certificate chain verification, providing a better user experience.

5.3. Limitations of MISO

IdP-mixer collusion

If the IdP colludes with the malicious host of the mixer, they can break the unlinkability by IdP since the host of the mixer can identify the RP and IdP connected to the mixer through their TLS public keys. This does not require breaking the TEEs. In practice, however, forming such collusion require a degree of trust between an IdP and the mixer, which can be hard to establish (in particular, most IdPs are big tech firms who will incur a reputation damage if such collusion is exposed).

Figure 8:Figure 8: Concurrency is shown in average login time. Each user sends one login request.

Account linkage from network-level identities

We note that malicious RPs can achieve linkability across RPs through users’ IP addresses. To preserve unlinkability across RPs, users need to use an anonymity network such as mix networks ^[57] or Tor ^[58]. If the user fails to use such networks, a curious mixer host can also link certain IP addresses with users. Even in this case, compared with the basic SSO (e.g., Google), a curious mixer in MISO still tracks much less user information, e.g., the mixer can only link network-level identities (not other sensitive user attributes like emails).

6.   Implementation and Evaluation

In this section, we present implementation and performance evaluation.

6.1. Prototype Implementation

To demonstrate the capability of MISO under different use cases, we implement a prototype that works under standard SSO authentication and Multi-IdP SSO authentication. The core task of prototype implementation is the mixer, which is implemented in an Intel SGX enclave.

We choose the open-sourced EGo SDK ^[59] to implement the mixer. EGo is a LibOS (Library Operating System)-based SGX SDK that supports the execution of Golang applications in SGX. A LibOS SGX SDK packs the important functions in the OS kernel into libraries and packs into an enclave directly, so as to avoid handling the interface between the OS and enclave manually. A great feature of EGo is that it provides easy-to-use APIs for remote attestation (to host a TLS server inside the enclave, a common approach is to let the enclave generate the TLS keys itself and bind it to a remote attestation statement). We use Golang’s native TLS package crypto/tls³ to provide services at the two protocol endpoints. As a TLS server, the mixer needs a set of certificates for client verification. Since the enclave should not trust the host’s root certificate, we obtain X.509 certificates that issued from Certbot⁴. We provide these certificates to the mixer by embedding (also a feature supported by EGo) them in the enclave binary. We use the prf12⁵ from package crypto/tls for our PRF function. Since the mixer plays different roles for the two types of OAuth 2.0 flows, and we use the OAuth 2.0 client-side package golang.org/x/oauth2⁶ for the mixer implementation as an OAuth 2.0 relying party, we use the OAuth 2.0 server-side package go-oauth2/oauth2/v4⁷ for the mixer implementation as an OAuth 2.0 identity provider. For persistent storage of long-term secrets of the mixer, we use the package ego/ecrypto⁸ for sealing keys and credentials inside the enclave.

Figure 9:Figure 9: Comparing MISO with basic SSO

We implement two mixer-side enclaves to support the standard SSO workflow and a 2-of-3 Multi-IdP SSO workflow in about 1.7k lines of Golang code in total. To demonstrate the full usage scenarios, we also implement an RP ⁹ that supports OAuth 2.0 standard in Golang. For both the mixer and the RP, we build web pages for the demo presentation. We use commercial off-the-shelf IdPs, in particular, Google, Facebook, and Github. There is no specific requirement for user-agents, and we have tested the prototype with Google Chrome and Apple Safari. Demo of our prototype is presented in § E.

6.2. Performance Evaluation

To evaluate the performance of MISO prototype, we pose the following research questions, two general ones and two SGX related ones:

Q1. What is the scalability of MISO (the standard and the Multi-IdP one) under increasing user concurrency?

Q2. How long is the latency introduced in standard MISO compared with a basic (without the mixer) SSO?

Q3. How big is the overhead caused by the use of SGX?

Q4. What are the performance differences between different SGX sealing modes, i.e. MRENCLAVE and MRSIGNER?

Experiment setup

We deploy the mixer enclaves on a server running Ubuntu 22.04.2 LTS on an Intel ^® Xeon ^® E-2274G CPU with 30GB RAM. In order to avoid the variance of network latency between the IdP and the mixer, we set up all the servers including the mixer, the IdP, and the RP on the same machine. For simplicity, we assume a selective disclosure policy where the user shares none of her identity attributes with the RP.

The latency we tested is the end-to-end time from the beginning to the end of the user login, i.e., the user login time. We use the Apache Jmeter™ ^[60] to create concurrent users’ log in requests. The level of concurrency is the number of different users trying to perform SSO login per second. We simulate different levels of concurrency with the duration of each test for 1 minute.

Answer to Q1

To answer Q1 , we deploy two enclaves of the mixer, one for the standard SSO workflow and one for the 2-of-3 Multi-IdP SSO workflow. The heap size for both enclaves is adjusted to 4096MB. We measure the latency and the standard deviation, the results are shown in Figure 8. Results suggest our prototype can handle about 1000 concurrent users. At 1000 concurrent users/ sec, the prototype provides a latency of 2.20 seconds for the standard SSO and 3.11 seconds for phase II of the 2-of-3 Multi-IdP SSO.

Answer to Q2

To answer Q2 , we compare the standard MISO SSO with the basic SSO (OAuth 2.0 protocol) without the mixer under the same codebase. The performance comparison is presented in Figure 9. Results suggest MISO roughly incurs 2× more latency when comparing with the basic one — This is in line with our intuition because MISO nests 2 (basic) SSO workflows at a higher level.

Answer to Q3

To answer Q3 , we run tests in which the mixer is not implemented with SGX as (insecure) baselines to demonstrate the overhead introduced by SGX. The results are shown in Figure 8. We use $\bar T$ to denote the average latency under all concurrency with a specific SSO prototype, i.e., the standard one or the 2-of-3 Multi-IdP SSO. We use ${\bar T_{baseline{\text{ }}}}$ to denote that without SGX (insecure baselines). The overhead caused by SGX O _SGX is calculated as: $$\begin{equation*}{O_{{\text{SGX}}}} = \frac{{\left( {\bar T - {{\bar T}_{baseline{\text{ }}}}} \right)}}{{{{\bar T}_{baseline{\text{ }}}}}} \times 100\% \end{equation*}$$

For Q3 , the overhead for the standard MISO SSO is 14.67%, and that for the phase II of the 2-of-3 MISO SSO is 13.91%.

Answer to Q4

SGX supports two sealing modes: MRENCLAVE mode that allows only the enclave binary itself to decrypt the encrypted data, and MRSIGNER mode that allows the binary signer to decrypt. The performance of these two sealing modes is also presented in Figure 9. The performance difference is minimal. This is mainly because there are not many operations involving sealing in the login workflow, so its overhead is insignificant relative to network latency and CPU fluctuations. We use the MRENCLAVE mode by default ¹⁰.

Comparison with previous work

It is difficult to give a rigorous performance comparison with most related works, since the experiment setups are different (e.g., EL PASSO ^[25] deploy their IdP and RP on cloud, but the user-agent on a local device, we deploy the IdP, RP, and user-agent on a same server), thus the roundtrip latency involved in the protocols are also hard to estimate ^{[23],[25],[26]}. We compare two aspects of MISO with other related works: concurrency and latency. Firstly, MISO is more scalable under high user concurrency (below 800). We notice that in EL PASSO, the latency deteriorates seriously as the concurrency exceeds 200 (see ^[25], [Figure 7]). We only find UPPRESSO ^[26] enjoys the similar experiment setup with MISO. The latency of UPPRESSO is 2.84× over basic SSO without mentioning of concurrency. Their experiment also suggests that the latency of SPRESSO ^[23] is 3.02× over basic SSO. In comparison with these two works, MISO has a shorter latency of 2.19× over basic SSO under 200 concurrency. In conclusion, MISO achieves shorter latency and higher scalability compared with previous works.

In a real-world deployment, the overhead of network communication between users, IdPs, RPs, and the mixer could grow larger due to their distances. However, this cost is incurred by all deployed SSO systems. In addition, the mixer can be distributed across multiple SGX instances on more servers if a higher concurrency is desired.

7.   Discussion

In this section we discuss the compatibility of MISO with OAuth 2.0 implicit grant flow, the OIDC protocol, and authorization. Afterwards we point out future extensions for our system.

Compatibility with the implicit grant flow

Although our protocol specified Figure 4 is built over OAuth 2.0 authorization grant flow, MISO is also compatible with the implicit grant flow ^[5], [§4.2]. When working with the implicit grant flow in the inner OAuth 2.0, the mixer can directly obtain token_mixer from the response of the authorization request instead of code_mixer. The steps during which the mixer exchanges code_mixer for the token_mixer are omitted (steps 4 5 in Figure 3). Similarly, when working with an RP in the outer OAuth 2.0, the mixer issues token_RP as a hash fragment to the user-agent, then let the user-agent pass it directly to the web-based RP, and steps 9 10 in Figure 3 are omitted.

However, we discriminate the implicit grant flow from the authorization grant flow because it offers less security guarantee, and it is vulnerable to user impersonation attacks ^[5], [§10.16]. Thus, the usage of this flow should be limited to web-based, public RPs (see § A.2) that are unable to authenticate themselves with the IdP, e.g., native applications installed on the user’s device ^[5], [§9].

Compatibility with OIDC

MISO is compatible with OIDC. In OIDC protocol, an IdP issues an ID token along with the access token in response to the token request, see Figure 2 step 4. An ID token is a JSON Web Token (JWT) ^[62] signed by the issuer IdP, in which concludes claims about the user’s identity information (e.g., user identifier and email). Therefore, the RP can obtain the user identifier directly from the ID token in OIDC, without retrieving it from the IdP using the access token as in OAuth 2.0. The uid in our protocol is identical to the sub field of an ID token ^[18], [§2]. When working with OIDC, the protocol st\eps in which the mixer retrieves user identifier and other attributes are omitted (steps 6 7 10 11 in Figure 3). Our prototype supports Google (OIDC-based) as the IdP, demonstrating this compatibility.

Privacy-preserving authorization

Authorization , the ability to empower a third party (RP) to act on behalf of the user to require resources from the IdP (a.k.a. resource server), is supported by OAuth 2.0 from the beginning. Hence, MISO adapts to authorization without modifying the protocol workflow. However, the mixer may need to manage more fine-grained privacy policies for the user when the resources required by the RP conflict with privacy-preserving goals.

The mixer’s involvement in MISO

An malicious RP may wish to redirect the user-agent to the IdP directly instead of the mixer to go through a normal SSO. However, if the RP does this, the authentication step (step 2 in Figure 3) in later interactions would be distinguishable from the user. The user can clearly notice that the malicious RP wants to obtain the user’s authorization instead of the mixer in a consent window like Figure 15(c), i.e., it would appears to be "If you continue, ... with ‘MyApp’ " instead. Then, the user can simply deny the consent to terminate this SSO instance.

Future works

One possible extension is to make use of multiple TEEs (potentially heterogeneous ones from different vendors, such as ARM TrustZone ^[63],[64], AMD Secure Encrypted Virtualization (SEV) ^[65], GPU TEEs ^[66],[67], and Keystone (RISC-V) ^[68]) to further decentralized the trust the mixer. MPC and hybrid approaches (e.g., combining TEE with MPC) are also interesting future directions to explore.

8.   Related Work

Our paper is generally related to four lines of works: 1) privacy-preserving SSO schemes that augment single sign-on workflow with privacy guarantees; 2) anonymous credentials that achieve similar privacy goals but in a different model (i.e., they are not single sign-on); 3) decentralized identity schemes which bear similar ideas to our Multi-IdP SSO protocol design; 4) works that also leverage TEE to address authentication and authorization-related problems.

8.1. Privacy-preserving SSO and Anonymous Credentials

We classify prior and the most related works on privacy-preserving SSO and anonymous credential schemes in Table 2. The major difference is that the latter does not satisfy SSO properties as defined in § 2.1.

Privacy-preserving SSO

OIDC core 1.0 ^[27] specifies a privacy protection mechanism, namely the Pairwise Pseudonymous Identifier (PPID) to provide RP unlinkability. When using the PPID feature, the IdP issues an identifier (PPID) that identifies the user to the RP, which cannot be correlated with the user’s PPID at another RP. However, the IdP records a user’s PPIDs for a certain RP, thus violates IdP unlinkability. The Mozilla BrowserID (a.k.a. Persona) ^[15] is the very first commercial SSO solution that aims for privacy protection. However, severe security attacks like malicious RP impersonation attacks are discovered by Fett et al. in ^[77] and it is no longer supported in the market. PseudoID ^[69], a privacy-preserving SSO solution based on the OpenID ^[32], utilizes blind signatures. The user is required to blind a token and then present it to the IdP. Later the IdP asserts the token and lets the user log in to the RP. The blind signed token contains no RP identity, and such tokens are unlinkable by the RPs. Thus unlinkability towards IdP and RP are both achieved. However, in this system, the user uses her secrets to log in to the RP, which adds extra steps to the login process. Fett et al. proposed SPRESSO ^[23], in which they achieved IdP unlinkability. Their solution also breaks the direct communications between the IdP and the RP with a client-side agent called the forwarder. The RP uses a pseudo-identity for each login to hide its identity. However, the IdP returns the same user identifier to the RP each time, which results in RP unlinkability. In PRIMA ^[24], a solution built over Oblivion ^[78], decouples the communications between the IdP and the RP. The IdP signs the credentials with a key and user’s attributes. The user uses the key to convince the RP about her identity. This solution gives much burden to its user in comparison with a purely SSO scheme. It does not provide RP unlinkability. Apple’s Sign in with Apple service ^[8] can cope with private email relay ^[28] to allow the user to use an anonymous email address to log in to RPs. Thus, the user’s email address is protected, and she can still receive emails from the RP with the relay service. Apple’s solution can not provide IdP unlinkability unless the user fully trust Apple. Furthermore, it limits users to use Apple as the only IdP choice and relies on their own infrastructure and software. Hammann et al. proposed the Privacy-Preserving OpenID Connect (POIDC) with the pairwise POIDC ^[19], two protocol extensions for OIDC. The pairwise POIDC offers both IdP unlinkability and RP unlinkability. However, it involves a zero-knowledge proof (ZKP) between the parties that brings more cost. They have not implemented their protocols so the performance is not given. Li and Mitchell point out POIDC is unpractical in ^[16]. Grassi et al. proposed the Privacy-Enhanced Identity Brokers ^[79], which introduce a similar broker design to achieve the privacy goals. However, they don not specify the protocol and are unclear about how to achieve the trustworthiness of the broker. El PASSO ^[25] is a privacy-preserving asynchronous SSO solution, in which the user obtains her anonymous credentials from the IdP and keeps them. When logs in to the RP, she proves the ownership of her credentials and selectively discloses her attributes. However, the user is required to be authenticated by the RP during each login, which is kind of against the original wishes of single sign-on. UPPRESSO ^[26] provides both IdP and RP unlinkability. During each login, the user and the RP negotiate a pseudo-identity and send it to the IdP, later the IdP returns the user’s pseudo-identity to the RP. However, it requires modification for the IdP and only supports the OIDC implicit grant flow.

Anonymous credentials

Anonymous credentials systems allow users to use a secret key to log in to the RP. However, most of such solutions do not support SSO features defined in § 2.1, not to mention the OAuth 2.0 legacy compatibility. We list popular solutions in Table 2 because they are still sound solutions for user privacy protection. Systems like U-prove ^[70],[71], ABC4Trust ^[72],[73], UnlimitID ^[74], IRMA ^[75], and Hyperledger Fabric Idemix ^[76] all provides IdP and RP unlinkability (IdP unlinkability is partially supported in UnlimitID). The biggest drawback of these systems is that the user needs to take care of the secret key in such systems. Most anonymous credentials solutions require specific user-side installations for credentials management and also suffer from noticeable user-perceived overheads for computing the anonymous credentials. Thus, anonymous credentials systems are seen as less adopted in the market in comparison with prominent SSO protocols such as OAuth 2.0 and OIDC. In conclusion of Table 2, MISO is the very first OAuth 2.0-compatible privacy-preserving SSO solution.

8.2. Decentralized Identity

Decentralized identity, a.k.a. self-sovereign identity, is an identity management scheme that allows the user to self-control her identity without relying on a centralized IdP. Unlike traditional identity management systems, in which exists a specific, centralized, and trusted entity (IdP) takes charge of the issuance, control, and maintenance and control of a user’s identity. Initiatives such as the W3C Decentralized Identifiers (DIDs) work group ^[80] and Decentralized Identity Foundation ^[81] have been developing standards to support decentralized identity. However, an obstacle to the large adoption of such DID systems ^[82]–^[84] is that they fail to leverage users’ identities available through existing web services, such as conventional centralized and federated identity systems. In MISO, our Multi-IdP SSO workflow is legacy-IdP-compatible, which supports users to port identities from existing SSO-based identity services, e.g., Google, Facebook, and privacy-preserving as well. Maram et al. proposed CanDID ^[30], a platform for the practical, user-friendly, and privacy-preserving realization of DID. Their approach is also legacy-compatible but different from ours: they leverage an oracle, e.g., DECO ^[85] or Town Crier ^[47] to port identities from existing web services. Torus ^[86] is a secure passwordless authentication and private key management platform which integrates OpenLogin ^[87] (now web3auth ^[88]). The OpenLogin is an authentication scheme also facilitates OAuth 2.0 standards. However, their approach does not offer as many privacy-preserving features as MISO does, e.g., the initial login requests a user’s minimal public information, users can not selectively disclose the information at the IdP side. Also, like Apple, Torus only claims but not guarantees that they log the user out of her 3rd party account immediately after her identity is verified.

8.3. TEE-based Authentication and Authorization Systems

TEEs are widely adopted for many scenarios. For example, Intel SGX, in particular, has been utilized in various applications, including high performance state-machine replication protocol ^[89], secure Linux containers ^[90], secure and privacy-enhancing Tor ^[91], and decentralized private web search extensions ^[92]. To the best of our knowledge, there is no available study to address privacy-preserving SSO or federated identity solutions using TEE. Few works show TEE’s capabilities in authentication and authorization. Zhang et al. proposed Town Crier ^[47], which provides authenticated data feed for smart contracts. Town Crier serves trusted off-chain data from existing web services to smart contracts. Despite Town Crier runs a full web session inside a TEE, using Town Crier to implement similar SSO tasks completed by MISO requires no less effort than implementing MISO itself. Matetic et al. proposed DelegaTEE ^[93], which leverages TEE to achieve delegation. DelegaTEE works mainly for sharing credentials between the user and third parties. Although it can be modified to perform the authorisation task similar to SSO. A key technical difference is that MISO does not require the user to deposit her credentials on the mixer/TEE, which makes MISO more robust to side-channel leakages.

9.   Conclusion

In this paper, we present the first legacy-(OAuth 2.0)-compatible privacy-preserving SSO authentication architecture, namely MISO. We enforce TEEs for realizing the system. MISO achieves four security and privacy goals: user account unlinkability by the IdP, unlinkability across RPs, selective disclosure of user identity, and robust to single-point failure. Our solution requires no modifications to commercial off-the-shelf IdPs. MISO works with two authentication workflows, SSO workflow under the setting of a single IdP and the Multi-IdP SSO workflow under a setting of multiple IdPs, which demonstrates the potential and flexibility of our system. We provide security analysis to our system, which shows that MISO preserves security and privacy against powerful attackers. Our prototype implementation and evaluation suggest that MISO enjoys high usability in real-world applications.

Positioning

We believe that MISO can significantly enhance security and privacy for a wide range of Internet users due to the large deployment of the SSO authentication infrastructure. Most importantly, MISO is highly practical since it is the first OAuth 2.0-compatible privacy-preserving SSO solution to date.