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.
Single Sign-On Protocols in the Wild
Identity Provider: Apple
- 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.
Identity Provider: Google
- 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.