Advertising

SponsoredTweets referral badge

Security And Privacy Of Social Logins (I): Single Sign-On Protocols In The Wild

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.
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. 

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. 

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
Related articles

  1. Hacker Tools Github
  2. Pentest Reporting Tools
  3. Hacker Tools For Ios
  4. Hack Tools Online
  5. Underground Hacker Sites
  6. Pentest Tools Online
  7. Hack App
  8. Nsa Hack Tools
  9. Hacking Tools 2020
  10. Hak5 Tools
  11. Free Pentest Tools For Windows
  12. Hacker Tools For Pc
  13. Pentest Tools Port Scanner
  14. Wifi Hacker Tools For Windows
  15. Hack Tools
  16. Tools Used For Hacking
  17. Hacking Tools Download
  18. Hacker Search Tools
  19. World No 1 Hacker Software
  20. Hacking Tools Download
  21. Pentest Tools Nmap
  22. Hacking Tools Windows
  23. Hack Tools Online
  24. Hacker Tools For Pc
  25. Top Pentest Tools
  26. Hack Tool Apk
  27. Tools 4 Hack
  28. Beginner Hacker Tools
  29. Best Hacking Tools 2020
  30. What Are Hacking Tools
  31. Free Pentest Tools For Windows
  32. Hacking Tools For Mac
  33. Hacking Tools And Software
  34. Pentest Tools Alternative
  35. Hack Tools For Mac
  36. Hacking Tools Mac
  37. Pentest Tools Alternative
  38. Pentest Tools Alternative
  39. Hacker Tools 2020
  40. Hacking Tools Pc
  41. Hacking Tools Windows
  42. Install Pentest Tools Ubuntu
  43. Pentest Tools Nmap
  44. Pentest Tools Subdomain
  45. Pentest Box Tools Download
  46. Hack Tools For Pc
  47. Hacking Tools For Windows
  48. How To Hack
  49. Tools 4 Hack
  50. Pentest Tools Android
  51. Hack Rom Tools
  52. Pentest Tools For Ubuntu
  53. Hackrf Tools
  54. Android Hack Tools Github
  55. Blackhat Hacker Tools
  56. Free Pentest Tools For Windows
  57. Hacking Tools Software
  58. Tools For Hacker
  59. Pentest Tools Android
  60. Nsa Hack Tools Download
  61. Hacker Tools For Pc
  62. Hacking Tools Software
  63. Pentest Tools
  64. Hacking Tools Usb
  65. Hak5 Tools
  66. Hacker Search Tools
  67. Pentest Tools Android
  68. Hacking App
  69. Hack Tools For Windows
  70. Hacker Tools Apk
  71. Hack And Tools
  72. Pentest Tools Download
  73. Pentest Tools Framework
  74. Hacking Tools For Beginners
  75. Pentest Tools Website Vulnerability
  76. Hacking App
  77. Hack Tools For Ubuntu
  78. Pentest Tools Windows
  79. Pentest Tools For Android
  80. Hacker Hardware Tools
  81. Hacking Tools Hardware
  82. Tools Used For Hacking
  83. Hacking Tools For Windows
  84. Hak5 Tools
  85. Hacker Tools For Ios
  86. Tools 4 Hack
  87. Pentest Tools Bluekeep
  88. Hack Tools For Ubuntu
  89. Tools For Hacker
  90. Pentest Tools Kali Linux
  91. Hacker Tools For Windows
  92. Pentest Tools Website Vulnerability
  93. Hack Tools
  94. Pentest Tools Url Fuzzer
  95. Top Pentest Tools
  96. Hackers Toolbox
  97. Hacks And Tools
  98. Pentest Recon Tools
  99. Hacker Security Tools
  100. Hacking Tools And Software
  101. Pentest Tools Nmap
  102. Pentest Tools Alternative
  103. Hack Tools For Mac
  104. Hacker Tools Mac
  105. Computer Hacker
  106. How To Install Pentest Tools In Ubuntu
  107. Hack Tools For Windows
  108. Hacking Tools Hardware
  109. Pentest Tools Bluekeep
  110. Pentest Tools Online
  111. Hacker Tools Software
  112. Pentest Tools For Ubuntu
  113. Hack Tools Mac
  114. Hack Tools Mac
  115. Hack Tools For Mac
  116. Tools For Hacker
  117. Hacker Tools Apk
  118. Pentest Tools Port Scanner
  119. Hacking App

Freelancer