> when you click on the login button, you're sent to whatever site the site you're logging in to wants to send you. It could be a fishing page or whatever. Is t

> when you click on the login button, you're sent to whatever site the site you're logging in to wants to send you. It could be a fishing page or whatever. Is that not a significant issue? You can (and should) restrict which URIs are allowed for the callback after authentication. Social authentication providers typically mandate this be a specific domain or list of domains, which essentially creates an explicit allowlist. However, of course, nothing stops a threat actor from abusing social authentication anyway. They can just create the integration client on the social platform’s developer console and use the system as intended. That is true of any federated and open-for-business authentication provider. I don’t say that in the spirit of criticism of course. > I feel like there needs to be browser-side integration that keeps track of which identity providers you have, and which ones you've previously used on which sites. Somehow facebook pushed passkeys through, so it's not like browser-site cooperation can't happen in the login space. 1Password had made a big deal about exactly that feature as being a foundation for the “1Password Future”, and then abruptly stopped talking about it. It exists in the client apps but it’s a bit clunky and they seem to have stopped improving it. If you’re using Apple ecosystem devices, there is a default-enabled setting to silently setup passkeys with sites that support doing that. You can disable it in the settings of the Passwords app. It seems to be a per-device setting, which is ridiculous because the passkeys get synced regardless, if iCloud Keychain is enabled.