KazeNoSekaii

fauzt

This post is the first out of three blog posts summarizing my (Louis Jannett) research on the design, security, and privacy of real-world Single Sign-On (SSO) implementations. It is based on my master's thesis that I wrote between April and October 2020 at the Chair for Network and Data Security.

We structured this blog post series into three parts according to the research questions of my master's thesis: Single Sign-On Protocols in the Wild, PostMessage Security in Single Sign-On, and Privacy in Single Sign-On Protocols.

Overview

Part I: Single Sign-On Protocols in the Wild

Although previous work uncovered various security flaws in SSO, it did not work out uniform protocol descriptions of real-world SSO implementations. We summarize our in-depth analyses of Apple, Google, and Facebook SSO. We also refer to the sections of the thesis that provide more detailed insights into the protocol flows and messages.

Identity Provider: Apple
Identity Provider: Google
Identity Provider: Facebook

Part II: PostMessage Security in Single Sign-On

It turned out that the postMessage API is commonly used in real-world SSO implementations. We introduce the reasons for this and propose security best practices on how to implement postMessage in SSO. Further, we present vulnerabilities on top-visited websites that caused DOM-based XSS and account takeovers due to insecure use of postMessage in SSO.

Part III: Privacy in Single Sign-On Protocols (coming soon)

Identity Providers (IdPs) use "zero-click" authentication flows to automatically sign in the user on the Service Provider (SP) once it is logged in on the IdP and has consented. We show that these flows can harm user privacy and enable new targeted deanonymization attacks of the user's identity.

Single Sign-On Protocols in the Wild

We presume basic knowledge of the SSO protocols OAuth 2.0 and OpenID Connect 1.0.

Also, you should be familiar with the postMessage API and the general concept of frames and popups in web browsers. Chapter 2 of the thesis introduces all basics.

To understand real-world SSO implementations, we selected three frequently used IdPs for detailed protocol analyses: Apple, Google, and Facebook. You can find an overview of all Authentication Request/Response and Token Request/Response messages in Appendix A.1 of the thesis.

Identity Provider: Apple

Sign in with Apple is intended for user authentication only, whereas the authorization part is reserved for future use. Besides native libraries for iOS, macOS, tvOS, and watchOS, REST endpoints provide SSO functionality to third-party native apps. Websites can integrate the JavaScript SDK that is based on these endpoints. Although the Authentication and Token Endpoints perform standard-compliant OpenID Connect Code and Hybrid flows (`response_type=code[&id_token]`, `response_mode=query|fragment|form_post|web_message`), there are some features in the authentication & consent part worth mentioning:

The native libraries are tightly integrated into the OS using the existing authentication on the device. Thus, biometric user authentication is possible.
Apple does not maintain an authenticated session at the IdP. Thus, each (web) SSO flow requires reauthentication.
The user authentication is protected with 2FA by default. If the 2FA succeeds, users can choose to trust the browser, which stores a cookie that supersedes future 2FA.
The scope is limited to the name, which can be modified, and email.
Users can choose to share their real email with the SP or request Apple to generate an anonymous random email that acts as a proxy between the SP and the user's email account.

More details are provided in Section 3.2 of the thesis.

Identity Provider: Google

The Google Identity Platform provides several identity tools, including:

Google OAuth 2.0 and OpenID Connect 1.0: Certified OpenID Connect endpoints enable user authentication and authorization for Google APIs (i.e., Calendar, Drive, and more).
Google Sign-In: Custom authentication SDK based on the OAuth 2.0 IDP-IFrame-based Implicit Flow and available for Android, iOS, and the web. The web SDK embeds a hidden proxy iframe on the SP website and uses the postMessage API to communicate between Google and the SP. Since the proxy iframe is same-origin with Google, it has access to the session, receives the Authentication Response, and forwards it to the SP utilizing the postMessage API.
Google One Tap Sign-In and Sign-Up: SDK for Android and the web that introduces the account creation process on websites with a single tap on a button. The web SDK presumes an active session on Google, embeds the consent page in an iframe on the SP website, and uses the Channel Messaging API for communication between the SP and Google. Therefore, the web SDK on the SP generates a new `MessageChannel` with two ports and transfers `port2` to the consent page iframe with postMessage. Henceforth, the consent page iframe sends messages (i.e., the `id_token`) to `port2` while the web SDK receives them on `port1` and vice versa.

Since the One Tap SDK is quite different from traditional SSO flows, we will briefly outline its unique use of new web APIs. The project initially launched as Google YOLO (You Only Login Once) and had a significant drawback: the consent page iframe was vulnerable to clickjacking. This issue was reported in early 2018 and fixed with restricted API access to trusted websites. Later, Google redesigned the SDK with the new Intersection Observer API v2 that it announced in February 2019:

Intersection Observer v2 introduces the concept of tracking the actual "visibility" of a target element as a human being would define it. [...] A true value for isVisible is a strong guarantee from the underlying implementation that the target element is completely unoccluded by other content and has no visual effects applied that would alter or distort its display on screen. In contrast, a false value means that the implementation cannot make that guarantee.

Source: Trust is Good, Observation is Better—Intersection Observer v2

This new API enables the consent page iframe to check whether it is visible on the SP website. If it is not visible, the iframe can block the consent or start alternative flows. Unlike the `X-Frame-Options` and `frame-ancestors` directives, Intersection Observer v2 does not prohibit iframe embedding. Still, it prevents clickjacking, which is helpful for the SSO consent page.

Sidenote 1: OAuth 2.0 Assisted Token describes a new flow that similarly embeds the consent page in an iframe but uses `X-Frame-Options`, `frame-ancestors`, or JavaScript frame busting as clickjacking mitigation. Since the IdP knows the SP to which it serves the consent page, it whitelists the SP origin within the framing directives, i.e., `X-Frame-Options: allow-from https://sp.com`:

Due to the use of an iframe to host the assisted token endpoint, the authorization server MUST take precautions to ensure that only trusted origins are allowed to frame it. The authorization server MUST prevent any origin from framing the assisted token endpoint except ones that an administrator has explicitly allowed.

Source: OAuth 2.0 Assisted Token

However, these anti-framing techniques do not prevent the trusted origins from executing a clickjacking attack to obtain consent by fraud. Thus, the IdP must take any measures deemed appropriate to ensure that the SP is trusted to not execute any clickjacking attacks. This limitation causes problems to public IdPs (i.e., Google and Facebook) as they certainly cannot ensure the trustworthiness of their self-registered SPs. If the SP cannot be trusted, the consent page must be protected against framing (i.e., using `X-Frame-Options: deny`) and alternative flows may be started.

We are confident that the Intersection Observer v2 API provides a promising concept for future "one-tap" SSO flows because it allows framing the consent page (and thus entire SSO flows in iframes) without the risk of clickjacking. Currently, only Chromium-based browsers are compatible with Intersection Observer v2, but this might change in the future.

Sidenote 2: If you analyze the security of postMessage on websites, you probably use a browser extension that logs all messages exchanged via the postMessage API. We developed a Chrome extension that logs all messages sent via the Channel Messaging API to the console. If you conduct postMessage security analyses, we highly recommend checking the Channel Messaging API as well.

More details are provided in Section 3.3 of the thesis.

Identity Provider: Facebook

Facebook Login implements the OAuth 2.0 protocol for data access authorization and user authentication. Although OpenID Connect 1.0 defines the signed `id_token`, Facebook issues an `access_token` for user authentication. The `access_token` provides authorized access to Facebook's Token Debugging Endpoint, which returns the `app_id` of the SP that this token is intended for (`aud` claim), the `user_id` of the user that owns this token (`sub` claim), the validity, the expiration, the associated scopes, and more.

Also, Facebook issues a `signed_request`, which is a base64url-encoded and symmetrically integrity protected token. It is not a JWT – instead, it prepends the HMAC to the claims as follows: `<hmac_bytes>.{"user_id": "[...]", "code": "[...]", "algorithm": "HMAC-SHA256", "issued_at": 1577836800}`. Although the `signed_request` does not include an audience (`aud`) claim, it implicitly provides audience restriction with its symmetric HMAC that is generated with the `app_secret` of the appropriate SP. If the SP successfully verifies the HMAC, it can assume that it was issued by Facebook for itself. The SP uses the `user_id` and `code` claims to authenticate the user, i.e., it retrieves the user entry matching the `user_id` from its database or redeems the `code` in exchange for an `access_token`, which is finally sent to the Token Debugging Endpoint.

Facebook does not issue `refresh_tokens` but instead distinguishes between short-lived (approx. 60 minutes) and long-lived (approx. 60 days) `access_tokens`. Short-lived tokens are converted into long-lived tokens with `grant_type=fb_exchange_token` at the Token Endpoint. If long-lived tokens expire, the SP needs to restart the login flow from scratch to receive new short-lived `access_tokens`.

More details are provided in Section 3.4 of the thesis.

Acknowledgments

My thesis was supervised by Christian Mainka, Vladislav Mladenov, and Jörg Schwenk. Huge "thank you" for your continuous support, advice, and dozens of helpful tips.

Also, special thanks to Lauritz for his feedback on this post and valuable discussions during the research. Check out his blog post series on Real-life OIDC Security as well.

Authors of this Post

Louis Jannett

More articles