People need to see which method they used to sign in

What it is

On return, people often remember only that they used “one of the big buttons,” not whether it was Apple, WeChat, or an email typed that day. Seeing which method was used means the product keeps a stable list that does not depend on memory: bound providers, local email or phone, and which of them last succeeded. This entry is about return identification. It is not about dependency risk, and not about whether the grant copy listed the right scopes.

Why it happens

Federation hides the primary key behind a provider brand. Months later, facing a row of buttons, people click by elimination. The wrong provider creates a new account, or yields “this email is already registered—please sign in” that does not match the original grant. The mailbox may be a provider-generated relay that does not match the address they use daily, so recall fails. A login page that offers only buttons and no “last used” leaves people hunting external cues (a password manager, a welcome mail) that are often filed as spam. The list turns “who am I” from recall into recognition.

Studying it

In return visits weeks apart, compare presence or absence of a “last method” hint and of a bound-method list, and measure entry into the original account.

Independent variables: last-success hint on the login page, full binding list inside the account, whether an unverified visitor can query bindings via a verified contact without revealing whether the account exists. Dependent variables: one-shot return into the original account, accidental duplicate accounts, share of “I cannot get in” tickets that were actually the wrong provider.

Same-day lab register-and-return does not measure forgetting. Store screenshots and welcome mail leak the method; experiments must control those cues. A binding-query flow that is careless becomes an account-enumeration channel; record that security side effect separately.

Where it stops holding

On a shared device, “last used: X” leaks identity to the next person; the hint must follow the session and clear on sign-out, not be stamped onto the hardware. With only one method, the list has no choice value, but settings should still show the binding for when a second method is added. Enterprise SSO users are redirected by the IdP and need not guess buttons, yet still need a history of bindings after they leave that IdP. To limit enumeration, an unauthenticated email field must not answer “this is bound to WeChat”; the signed-in settings page is where the full list belongs.

Applying it

• In signed-in account settings, list every sign-in method and when it was bound, distinguishing “can be used to sign in” from “profile source only.”
• On a private device’s login page, a dismissible “last success on this device: X” reduces random taps; it must vanish after sign-out or a user switch.
• Welcome mail and the username stored by a password manager must match the identifier shown in the UI, so a relay mailbox does not exist only in email while the button shows a brand.
• Verify with a two-week return: product only, no notes. Count entry into the original account separately from a second account created by mistake and from giving up after the wrong button. On the settings page, ask people to point to the methods they can use; a wrong point is a failed list.

Related

• Within the group: H6.02.1 Third-party login cuts typing but creates dependency · H6.02.2 Disclose which information the provider will share
• Adjacent: H6.13 Account switching and multiple accounts · H6.11 Password recovery and reset · H6.07 Sign out
• Search terms: login method recall · account linking · federated identity