Third party cookie mitigations

OIDC front-channel logout, session management, and background token renewal generally use third-party cookies in the same ways. This table offers a variety of options for mitigating the deprecation of third-party cookies on your site.

There will be trade-offs; no solution is a one-to-one replacement. This table offers developers a place to start when considering what changes they will need to make to their services in order to continue to support the federated authentication components that currently require third-party cookies.

Proposed Solution	Known Limitations	RP Impact	IdP Impact	User Impact	Privacy Impact	Chrome	Edge	Safari	Firefox	Notes
OIDC Backchannel Logout		net new development	net new development	none	changes	no impact
OpenID Shared Signals and Events		net new development	net new development	none	changes slightly	no impact
Storage Access API	not currently supported by Chrome; Safari requires a direct user interaction and taking the user to the third-party site so the user has a first-party interaction with the domain; Nested iframes may not be supported;	must change	none	prompt per RP on logout on IdP	improved	not favorable	supported	supported	supported
Storage Access API w/ Forward Declaration	not currently supported;	some changes	changes	single prompt	improved	not favorable	favorable	interested	no signal
Federated Credentials Management		none	changes	prompt per RP on login	improved	dev trial	interested	no signal	no signal
First Party Sets (same set)	under development; limit to the number of domains in a set; a domain can only be a member of a single set; likely to require that all domains share the same privacy policy;	hosting metadata	generally none, but if the IdP is owned by the same organization as the RPs, it would also host the metadata	none	changes	finished an Origin Trial; in progress;	interested	not favorable	not favorable	limited use cases; you can test FPS by following Google's instructions in this Developer blog post
Login Status API	under development; may require the user to go through a flow the browser can verify; may require user interaction/engagement to stay logged in;	small change	small change	none	no change	no signal	no signal	favorable	no signal
CHIPS	partition is double-keyed on protocol and domain of the top-frame as well as the cookie's host key; n/a to federated logout scenarios	none	would need to add the Partitioned cookie attribute to their cookies	none	changes slightly	Origin Trial in progress	interested	interested	interested
Administrative controls		none	none	none	needs discussion	supported	supported	?	?	limited use cases
End user controls		none	none	understand and make change	impact beyond use case	tbd	tbd	tbd	tbd
Do nothing		user stays logged in	can't notify RP of session change	confusion, unintentional account access	unintentional account access	n/a	n/a	n/a	n/a
Create custom domain (architectural changes)	If you have only one RP and own fed flow, you can keep the code by creating a custom domain that turns your IdP into the same domain as your app; requires domain administration;	none	infrastructure changes	none	changes (masking ownership)	no impact	no impact	blocks CNAME requests from known tracking domains	block CNAME requests from known tracking domains