Signing In With an Account You Have

Stage: the button instead of the form. In control: your identity provider.

1. The button replaces a password with a permission

Choosing the provider button instead of the registration form swaps a pair of credentials for a grant. Instead of creating an address and password that the site holds forever, you authorise a provider you already have an account with to vouch for you, and that authorisation can be withdrawn later from a single place.

What the site ends up with is a statement from the provider saying that the person at this browser is the same person it knows by a particular identifier. The site trusts the provider, the provider trusts you, and no shared secret between you and the site ever comes into existence.

That is genuinely less than a signup form takes, and it is also more than nothing. Both halves of that sentence matter, and the parts that get lost are usually on the second half.

2. Four things travel to the site, and a password is not among them

The site receives a stable identifier for you within that provider, which is the value it stores as your account. It receives your address. It usually receives your display name and the picture on your profile, because those are requested by default in nearly every implementation.

Your password never moves. That is the core technical property, and it is worth being precise about why it matters: the site cannot leak what it does not hold, and a breach at a service you signed into this way exposes an identifier and an address rather than a credential that might be reused elsewhere.

What travels back the other way is worth stating too: the site learns nothing about the rest of your account. It does not get your contacts, your files, or the ability to read your mail. Those require separate permissions that the sign-in flow does not request.

3. The provider collects the list of everywhere you go

Each time you use the button, your identity provider records that you signed in to that service, and when. Over a few years that record becomes a fairly complete inventory of the services you use.

This is the part missing from most explanations of the feature, and the reason is structural: the explanations are written by the providers. The trade is real either way. You are exchanging a set of independent site accounts, each knowing only about itself, for one account that knows about all of them.

Whether that is a bad deal depends on what you are protecting against. Against a breach at a random small service, the provider button is clearly better. Against building a single profile of your activity in the hands of one company, it is clearly worse. Both statements are true at once, and choosing means deciding which one you care about today.

4. The day the provider account goes away takes everything with it

Losing access to the provider account means losing every service that used it as the door. Not the data inside those services, which usually still exists, but the ability to get to it.

Provider accounts are suspended for reasons that are automated, occasionally mistaken, and rarely explained on any schedule useful to you. They are also lost the ordinary way, through a forgotten password on a device that died. The result is the same: a queue of services asking you to prove you are the person the provider used to say you were.

There are two things worth doing before that day rather than after. Add a password to the important accounts where the service allows both methods, so the provider is a convenience rather than the only route. And keep a note of which services you signed into this way, because the provider's own list is on the far side of the door you cannot open.

5. Unlinking leaves the account behind

Every major provider keeps a page listing the services you granted access to, usually under security or connected applications settings, and every one of them lets you revoke a grant.

What revocation does is narrower than people expect. It stops the provider vouching for you at that service. It does not delete your account there, does not remove your data, and does not tell the service to forget your address. The typical result is an account that still exists in full and has no working way to sign in, which is worse than either deleting it or leaving it alone.

The order that avoids that outcome is to set a password on the service first, or delete the account at the service, and only then revoke the grant at the provider. Doing it the other way round leaves you knocking on a door you locked from the wrong side.

6. The button and a fresh address solve different problems

For a low-value service you will use a handful of times, the button is a reasonable choice: nothing worth stealing accumulates there, and you save yourself another password.

For anything that must outlive your relationship with the provider, it is the wrong choice, and so is anything you would rather not have filed under your main identity, because the provider button attaches the service to your real name and your real address by construction.

That is the honest comparison with a disposable address, and it is not a rivalry. A temporary address hides who you are from the site and gives you nothing to remember. The provider button tells the site exactly who you are and gives you nothing to remember. They answer opposite questions, and the same person will reasonably use both in the same week. When neither fits, generating an address for this one form is the third option and the least entangled of the three.

The handover

Control at this stage sits with the provider, and the reason to be deliberate here is that the grant outlasts your interest in the service. A smaller version of the same idea keeps the mailbox as the credential rather than the provider, and that is when the address becomes the password, while the version that removes the shared secret entirely is covered in what a passkey replaces. Whichever button you press, the address behind it still reaches the site, still enters the systems described in what happens the moment you submit, and is still worth money as the lookup key discussed in what an address is worth.