I don't know any website that uses facebook as its only way to authenticate. I never use the usual suspect for authentication, always choose the regular account option tied to an email address. That is what password managers are for anyway.

Do you mean passive third-party requests I could block on my end, or something built into their backend that exposes their entire registration list? I thought it was only the former.

Both. Facebook scans form fields for content that can be uploaded [0], and a developer can upload hashed data (I believe potentially from their backends[1][2]).

[0] https://www.facebook.com/business/help/611774685654668?id=12...

> Automatic advanced matching will tell your pixel to look for recognisable form fields and other sources on your website that contain information such as first name, last name and email address. The Facebook pixel receives that information along with the event, or action, that took place. This information gets hashed in the visitor's browser. We can then use the hashed information to more accurately determine which people took action in response to your ad. After matching, we promptly discard the hashed information.

[1] https://developers.facebook.com/docs/facebook-pixel/advanced... - technical specs for uploading hashed user content. Typically done on the frontend.

[2] https://www.facebook.com/business/m/signalshealth/accelerate...

> The manual method feature enables advertisers to leverage their own customer data, such as email address, phone number and so on. This method allows advertisers to report on more conversions, optimise their ads against more conversion data and reach more people on Facebook with their website Custom Audiences or dynamic ads.

This is not how it works.

In Android apps, that's how it works.

The SDK (recommended for login) is set up by default to collect information and installs handlers for app lifecycle events as soon as the app is installed. The default is to do this without requesting user consent.

A rough summary of the data: (Ad ID, device, locale, phone network, maybe install referrer).

To attribute advert -> install, Facebook ads pass on an encrypted blob containing campaign information to the Play Store, this blob is readable by the app, and is transmitted back to Facebook where it's decrypted.

The setting: https://github.com/facebook/facebook-android-sdk/blob/fcd4ef...

Defaulted to true: https://github.com/facebook/facebook-android-sdk/blob/5fe6e2...

https://developers.facebook.com/docs/app-events/getting-star...

Wow, that's a very dark pattern.

In any case, this is not how it's supposed to work in oauth, and it's definitely not required for it to work.

I suppose developers could pretty much use any generic oauth lib for the login purposes.

Maybe this is of interest for you: https://media.ccc.de/v/35c3-9941-how_facebook_tracks_you_on_...

Seems to me, this is pretty much exactly how this works.