The problem is that at that point in the flow, it's owned by the SSO provider. The SSO provider can't know with certainty what account has an active account with the website.

▲

armen52 5 days ago | parent | next [-]

I don't think that's true though? The OAuth provider knows which third parties you have authorized to have access to your account(s) as well as what information or privileges you've approved for each. And when you land on that screen, they know which third party referred you to them.

In other words, they could definitely highlight or otherwise hint to you which of the Google accounts you've already approved/used via one or more of your authenticated Google accounts.

	▲	creddit 5 days ago \| parent [-]
		The provider knows you have given those privileges _at some point_ but it doesn't know if that account still exists or anything about the state of the account. So, yes, they could do more to highlight _potential_ accounts but it's not the case that they have any visibility into the actual state of accounts.

▲

rtpg 5 days ago | parent | prev | next [-]

They could thought right? because if you login to a website (that's passed along an ID) then you would have that bit set.

I don't need to know for certain the account on the receiving side exists, just that I have signed in before with it. Facebook does this at least!

Like "has an account" isn't possible without leakage, but "has logged in through this flow before" (hell, stick timestamps in there too!) does.

One thought though: your SSO provider has that account list, but often prompts a re-login. So it could be that your SSO provider account picker _doesn't have access to your account information fully either_.

▲

ehsankia 5 days ago | parent | prev [-]

And I don't think it makes sense for the SSO provider to leak a list of all your accounts to the website either. That being said, I think the SSO provider could maybe track that information maybe?