Logout. The standard mechanism for OAuth logout is to iframe the relying parties (RPs aka apps) which is a third party cookie context. Redirecting to each RP is substantially slower because logout is serialized rather than parallelized and requires well behaved RPs as any badly behaved RP breaks logout for the rest of the RPs.

(This is why some browsers have a setting like "third party cookies after visited in a first party context" - first party for login, third party for logout. But advertisers screwed this up by asking sites to do full frame redirects through them. )

>>> The standard mechanism for OAuth logout is to iframe the relying parties

No it isn't.

OAuth2 doesn't specify cookies in the entire spec and definitely doesn't require third party cookies, especially for logout.

Here's the RFC: https://tools.ietf.org/html/rfc6749

OAuth is a family of RFCs, including 6749, 6750, and others. While 6749 is the minimum for OAuth2, in the specific case of the three largest providers under discussion, many other extension specs have been implemented. The OpenID connect logout spec has become the de facto logout spec for OAuth (as the OAuth RFC makes no mention of logout). All three providers mentioned implement it as the primary logout mechanism on the web.

Spec: http://openid.net/specs/openid-connect-frontchannel-1_0.htm

Edit: I should say, this spec also doesn't require cookies - you can use HTML5 local storage or another mechanism. In practice however, if you log into a Google service like YouTube, or a Microsoft service like Outlook, or a Facebook third party like Spotify, they use cookies.

Facebook widgets are used for tracking user across the web too. So one cannot protect user from being tracked without breaking those widgets.