"Sign in with ... Privacy'': Timely Disclosure of Privacy Differences among Web SSO Login Options

TL;DR

The paper tackles the lack of transparency in privacy implications across web SSO options by empirically analyzing top RP sites to identify four client-side implementation patterns and by introducing SPEye, a Chrome extension that surfaces IdP permission requests in real time. SPEye offers two workflows (Focused mode on IdP login pages and Comparative mode on RP login pages) to enable end users to compare privacy implications before committing to an SSO choice, adapting to location-specific differences and to evolving RP implementations. The authors validate SPEye with an empirical code-pattern analysis, show high coverage for standard OAuth/OIDC in Focused mode, and report notable but incomplete success in Comparative mode due to custom RP behaviors and IdP protocol deviations (e.g., Facebook's 2023 changes). They also demonstrate that presenting IdP permissions can influence login decisions toward more privacy-friendly options, and discuss limitations, practical deployability, and stakeholder-oriented recommendations for improving SSO privacy and user control. Overall, the work advances privacy-aware decision-making in web authentication by making SSO permission data transparent and actionable for end users and stakeholders alike.

Abstract

The number of login options on web sites has increased since the introduction of web single sign-on (SSO) protocols. Web SSO services allow users to grant web sites or relying parties (RPs) access to their personal profile information from identity provider (IdP) accounts. Many RP sites fail to provide sufficient privacy-related information to allow users to make informed login decisions. Moreover, privacy differences in permission requests across login options are largely hidden from users and are time-consuming to manually extract and compare. In this paper, we present an empirical analysis of popular RP implementations supporting three major IdP login options (Facebook, Google, and Apple) and categorize RPs in the top 500 sites into four client-side code patterns. Informed by these RP patterns, we design and implement SSOPrivateEye (SPEye), a browser extension prototype that extracts and displays to users permission request information from SSO login options in RPs covering the three IdPs.

Figures (7)

• Figure 1: Overview of OAuth 2.0 authorization code flow.
• Figure 2: Lack of transparent information at time of (a) user login prompt. When signing into Rakuten.com with (b) Google or (c) Facebook, the user is informed about permission requests only for the selected choice (typically after the user has committed to using that SSO). In (d), an attempt to login using Facebook without revealing the email address raises an insufficient permissions error on the RP site. Note the lack of justification on why data access is needed; to access this information, a user would need to navigate to and search a secondary page such as the RP's privacy policy.
• Figure 3: Implementation of an SSO request in three different code patterns.
• Figure 4: Architecture of SPEye and its two workflow modes. The Focused mode overlay button is displayed on every IdP login page, and the Comparative mode extension icon is available on a subset of RP login pages.
• Figure 5: SPEye's UI for (a) Focused and (b) Comparative workflow modes showing permission information on example sites. In the case of Apple SSO, SPEye also indicates Apple's privacy feature (not shown in this image but available on Apple's IdP UI) that allows the user to anonymize their information released to the RP. To get this view of permission data without SPEye, the user must login with each SSO option to manually collect, record, and compare the personal data requested.