Over the last decade, identity federation has played a central role in raising the bar for authentication on the web, in terms of ease-of-use (e.g. passwordless single sign-on), security (e.g. improved resistance to phishing and credential stuffing attacks) and trustworthiness compared to per-site usernames and passwords.
The standards that define how identity federation works today on the Web were built independently of the Web Platform (namely, SAML, OpenID and OAuth), and their designers worked within the Web's limitations.
Because of those limitations, existing user authentication flows were designed on top of general-purpose web platform capabilities such as top-level navigations/redirects with parameters, window popups, iframes and cookies.
Because those general purpose primitives can be used for an open-ended set of use cases (again, notably, by design), browsers have to apply policies that capture the lowest common denominator of abuse, at best applying cumbersome permissions (e.g. popup blockers) and, at worst, blocking primitives entirely (e.g. blocking third-party cookies).
Over the years, as low level primitives were abused, browsers intervened and federation adjusted. For example, popup blockers became common and federation adjusted to work in a world where popup blockers were widely deployed.
The challenge, now more than ever, is that some of these low level primitives are increasingly abused to allow tracking users across websites. As a result, browsers are applying stricter and stricter policies around the primitives.
Publicly announced browser positions on third-party cookies:
Blocking third-party cookies broke important parts of the protocols in those browsers (e.g. logouts) and made some user experiences inviable (e.g. social button and widget personalization).
While it is easier to see the current impact of third-party cookies, it is equally important to understand the ways in which the low level primitives that identity federation depends on (e.g. redirects) are being abused and the privacy principles browsers are using to increase control of those primitives, so that we don't paint ourselves into a corner.
If browsers are applying stricter policies around the low level primitives that federation depends upon, but with the assumption that federation is significantly better than usernames/passwords, how do we continue to enable identity federation?
The problem starts with classification.
When federation was first designed, it was designed within the existing capabilities of the web, rather than changing them. Specifically, federation worked with callbacks on top of cookies, redirects, iframes or popup windows. All are fundamental primitives provided by the web which didn't require any redesign, redeployment or negotiation with browser vendors.
One example of a low level primitive that federation depends on is iframes and third-party cookies. For example, credentialed iframes are used while logging out, for social buttons, and for widget personalization.
Unfortunately, the use of iframes is virtually indistinguishable from trackers that can track browsing history across relying parties, just by having users visit links (e.g. loading credentialed iframes on page load).
We call this the classification problem because it is hard for a browser to distinguish between these two cases: identity federation helping a user, versus users being tracked without any control.
Third-party cookies are already blocked in Safari and Firefox by default (and Chrome intends to block third-party cookies soon too) which makes these use cases inviable.
The problems then are:
- First and foremost, what Web Platform features need to be exposed to (re)enable these features of federation to co-exist with the absence of third-party cookies in browsers going forward?
- Secondarily, in which direction are browsers going that could potentially impact federation?
Before we prematurely jump into solutions for the first (and more urgent) problem, we think there is something more fundamental changing. Let's take a step back and a take closer look at the second problem: in which direction are browsers going that could more fundamentally impact federation?
While third-party cookies in iframes are used in federation, a more fundamental low level primitive that federation uses is top level navigations (e.g. redirects or form POSTs) to navigate the user to identity providers (with callbacks, e.g. redirect_uri) and back to relying parties with a result (e.g. an id_token):
This low level primitive also enables cross-site communication, namely via decorating links, which can be abused to track users without their control. This is called bounce tracking:
In this example of bounce tracking, websites redirect the user to a cross-origin website that automatically and invisibly redirects the user back to the caller, but passing enough information in URL parameters to enable the tracker to join that visit (e.g. when you visit rings.com) with visits to other websites (e.g. when you visit shoes.com).
In federation, that's less invisible/automatic, but it is still there. Cross-site tracking is enabled via federation when relying parties that the user signs in to collude with each other (and other entities) to deterministically (or probabilistically) link their users' accounts to build a richer user profile (e.g. one site selling data on browsing history for ads targeting to another service). While this could be enabled without federation (users could manually provide a joinable email address or phone number), federated identity providers have an opportunity to address this problem at scale by providing their users with site-specific/directed identifiers.
Because of these tracking risks, browsers are starting to disable third-party cookies in iframes and more generally provide tighter control over cross-site communication (e.g. a privacy model for the web).
Because this cross-site communication takes place in a general purpose medium, it is hard for browsers to distinguish between cross-site communication that is used for exchanging identity data deliberately (e.g. federation) or unintentionally (e.g. tracking).
Browsers can't readily classify federation; federation is inherently intended to support many (or arbitrary) agents.
The classification problem is notably hard because it has to deal with adversarial impersonation: agents who have an interest in being classified as federation to get access to browser affordances.
While the timelines for aggressive browser defenses against bounce tracking are farther in the future, proposed defenses much more fundamentally threaten federation.
Publicly announced positions by browsers on bounce tracking:
- Safari's existing deployed strategies and principles
- Firefox's protection against redirect tracking
- Chrome's stated Privacy Model for the Web
So, how do we distinguish federation from tracking and elevate the level of control while assuming adversarial impersonation?
There is no one answer, but we have a proposal as a starting point.