Preserving Federated Single Sign-On while Preventing Hidden Tracking in Browsers
July 8 ,2021
Over twenty years ago, IT architects and visionaries put together ideas for single sign-on services that spanned the Internet. They developed the Security Assertion Markup Language (SAML). As mobile devices became more prevalent, the limits of SAML led people to develop OAuth, and from there, OpenID Connect. And through all of this innovation and development, the most common medium for users to log in and access services and content was via the World Wide Web.
Single sign-on services that use a third-party's account information are known as "federated." An individual's federated identity is their identity information, hosted at one organization like their school, employer, or favorite social media service. It is used by various service providers to let a user login without creating a new account. The benefits to this arrangement include fewer passwords for a user to keep track of and fewer ways for a hacker to compromise service providers. If the service provider doesn't store the password, the password can't be hacked through their systems.
Several pieces of functionality in web browsers, known as primitives, enable the features that allow for federated single sign-on. One of those features is called a cookie. Cookies come in various types, but what they all have in common is that they put a small bit of code in a user's web browser. That bit of code can serve many different purposes: it can let a site know whether or not a user is logged in, it can be used to store information that will allow a service to personalize services in some manner, and, most infamously, it can be used to track what sites a user visits as they surf the web. From the browser's perspective, though, one cookie looks just like the next. The browser can't tell the difference between a cookie that lets a service know the user is authenticated from a cookie that allows an advertiser network to track a user around the web. And that's a problem.
As the world becomes more aware of the privacy implications of existing on the web, browser vendors like Google, Apple, and Mozilla are trying to figure out how to support federated single sign-on while preventing hidden tracking. Since the tools used by both are technically the same, this is a tricky problem to solve! In 2020, Google made a public statement that they would phase out one type of cookie functionality, the kind that lets services with domains outside the ones that initially set the cookie (also known as third-party or tracking cookies). While that would definitely make life more difficult for trackers, it also makes life more difficult for federated single sign-on - one site sets the cookies that says the user is properly authenticated, but sites unrelated by domain name won't be able to read that information.
Some browser vendors have already taken steps to block third-party cookies. Apple's Safari is at the forefront of blocking hidden tracking. But they are also a platform where services like Microsoft Teams just won't work. Mozilla's Firefox has partly implemented the limits on third-party cookies but is actively looking for ways to do this more efficiently. And Google is actively developing their Privacy Sandbox but has realized that killing third-party cookies without a plan for federated single sign-on is a problem.
Several proposals are being explored as potential ways to preserve federated single sign-on while preventing hidden tracking. Still, for right now, they are all just proposals. No one has a solution at hand, not even (or perhaps especially) not the browser vendors themselves. Since there is no solution ready outside of prototypes, the question of when third-party cookies will go the way of the old Flash protocol is still open. A new community group in the W3C is forming to consider this challenge in depth - stay tuned to learn more about what happens from here.