Saturday, June 03, 2023

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

Read more


  1. Hacking Tools Github
  2. Hacker Tools Apk Download
  3. Bluetooth Hacking Tools Kali
  4. Game Hacking
  5. Hacking Tools Kit
  6. Hacker Tools 2020
  7. Hack Tool Apk
  8. Pentest Tools Review
  9. Hacking Tools For Windows Free Download
  10. Hacker Security Tools
  11. Hacker Tools Linux
  12. Hacker Tools Apk
  13. Hacker Tools Apk Download
  14. Hacking Tools For Kali Linux
  15. Pentest Recon Tools
  16. Hack Tools
  17. Hacking Tools Online
  18. Hackers Toolbox
  19. Pentest Recon Tools
  20. Beginner Hacker Tools
  21. Hacker
  22. Game Hacking
  23. Pentest Tools Url Fuzzer
  24. Pentest Tools Website
  25. Hacking Tools For Mac
  26. Hackrf Tools
  27. How To Install Pentest Tools In Ubuntu
  28. Hacker Techniques Tools And Incident Handling
  29. How To Install Pentest Tools In Ubuntu
  30. Hack Tools Download
  31. Hacker Tools For Windows
  32. Hacker Tools For Pc
  33. Hacker Tools Apk Download
  34. New Hacker Tools
  35. Hack Tools Pc
  36. Hacker Tools Windows
  37. Hacker Tools 2019
  38. Pentest Box Tools Download
  39. Pentest Tools Bluekeep
  40. Install Pentest Tools Ubuntu
  41. Usb Pentest Tools
  42. Hack Tools 2019
  43. Pentest Tools For Ubuntu
  44. What Are Hacking Tools
  45. Hacker Tools 2019
  46. Black Hat Hacker Tools
  47. Hacking Tools For Windows 7
  48. Hacking Tools Download
  49. World No 1 Hacker Software
  50. Hacking Tools And Software
  51. Hack Rom Tools
  52. Hacker Tools Hardware
  53. Github Hacking Tools
  54. Tools Used For Hacking
  55. Hacking Tools For Games
  56. Hack Tools For Mac
  57. Growth Hacker Tools
  58. Hack Tools For Pc
  59. Growth Hacker Tools
  60. Hacker Tools For Mac
  61. How To Hack
  62. Pentest Tools Github
  63. Pentest Tools List
  64. Hacker Tools Free
  65. Pentest Tools Android
  66. Hack Tools Github
  67. Hacker Tools 2020
  68. Hack Tools Online
  69. Tools For Hacker
  70. New Hack Tools
  71. Pentest Tools
  72. Hack Tools Github
  73. Hacking Tools Windows
  74. Hacker Tools Apk
  75. Hack Tools Mac
  76. Pentest Tools Apk
  77. Pentest Tools For Android
  78. Hacking Tools For Kali Linux
  79. Hacking Apps
  80. Hacker Tools Windows
  81. Hack Tools For Mac
  82. Android Hack Tools Github
  83. Hacking Apps
  84. Pentest Tools Alternative
  85. Hacking Tools Usb
  86. Hacker Tools Free Download
  87. Android Hack Tools Github
  88. Usb Pentest Tools
  89. Hacking Tools For Kali Linux
  90. Hacker Tools 2019
  91. Hacker Tools For Mac
  92. Growth Hacker Tools
  93. Pentest Tools Kali Linux
  94. Hacking Tools For Beginners
  95. Hack Website Online Tool
  96. New Hack Tools

No comments:

Post a Comment