Connecting a sign-in to an account

The first sign-in

The printer keeps a table of sign-in identities, with one row for each provider account that may open a printer account. It looks there for the pair from the validated ID token:

Issuer:  https://auth.photos.example
Subject: user-2048

There is no row. That tells the printer only that this photo account has never been used to sign in to the printer. It does not tell the printer that you are a new customer. You might have opened a printer account with a password long before the photo button existed, and nothing in the ID token can distinguish those two situations.

A relying party can handle the missing row in two ways. It can create an account at once, using the claims as starting values, so that the first sign-in feels like every later one. That is quick, but it creates accounts for people who were only looking around, and it adopts a name and address the person never reviewed as the account's details. Or it can ask for registration details first: show a short form filled in from the claims, ask for anything the provider does not supply, such as agreement to the printer's terms, and create the account only when the person confirms.

The printer asks. Its registration page greets you as Robin Park and offers two choices: create a new printer account with the details shown, or sign in to an existing printer account and connect this photo account to it.

While that page is open, the printer has to remember who you are. The validated issuer and subject stay on the printer's server, in a pending registration attached to your session:

Pending registration (expires 15 minutes after the sign-in)
  Issuer:   https://auth.photos.example
  Subject:  user-2048
  Claims:   name Robin Park, email [email protected], email_verified true

The form carries only what you are allowed to choose. If the issuer and subject traveled in hidden form fields, the browser would send them back, and whoever submitted the form could put a different subject there and create a printer account tied to someone else's photo account. The identity has to come from the validated ID token, by a route the browser cannot touch. If you abandon the page, the pending registration expires and nothing is created.

A new customer who chooses to create an account gets a new printer account and a row linking it to their pair, written in one transaction so that neither can exist without the other. You have had a printer account since your first photo book, so you choose the second option instead. Linking accounts follows that path. Either way, the result is the same kind of row.

Returning customers

Once a row connects the pair to an account, every later sign-in is a lookup. On 1 October at 09:00, the sign-in that Following a complete sign-in traced step by step reaches this point, and the printer runs:

SELECT account_id
  FROM sign_in_identities
 WHERE issuer  = 'https://auth.photos.example'
   AND subject = 'user-2048';

The row points to printer account 8812, which is yours. No other claim takes part in finding it.

The comparison is exact. Both values are case-sensitive strings, so the printer does not lowercase them, trim them, or treat User-2048 as the same subject. The issuer is the one the printer configured for the photo service and validated the token against, compared character for character.

The table itself enforces the important rule:

CREATE TABLE sign_in_identities (
  account_id  TEXT NOT NULL REFERENCES accounts(id),
  issuer      TEXT NOT NULL,
  subject     TEXT NOT NULL,
  linked_at   TEXT NOT NULL,
  UNIQUE (issuer, subject)
);

A pair can appear only once, so one photo account can never open two printer accounts. The constraint covers the pair, not the subject alone. When the printer added the mail service, your account there arrived with the subject a94f1c07e2, and Supporting several providers pointed out that another provider is free to issue user-2048 to someone else entirely. A lookup by subject alone could hand that stranger your account. Account 8812 can have several rows, one for each provider you link, and each row is checked on its own.

A lookup by email address would fail in the ways Claim stability and privacy described. If you change your address at the photo service to [email protected], the pair still finds account 8812, and the printer updates its copy of the address. A lookup by email would find nothing and offer you a second account, or find an account that now belongs to whoever has been given your old address.

Two outcomes need more than a plain match. If the row points to an account the printer has suspended or closed, a valid ID token does not reopen it. The provider vouches for who signed in, and the printer still decides what that person may do. And if the lookup fails for people the printer expects to recognize, for example after a provider moves to a new issuer identifier, or after a change of host alters pairwise subjects as Public and pairwise subject identifiers described, the printer has a migration to plan. Falling back to matching email addresses is not a way to cover the gap.

What the account stores

After your photo account is linked, a simplified view of the printer's records for you looks like this:

Account 8812
  Display name:    Robin Park
  Contact email:   [email protected] (confirmed by the printer, 2025-11-14)
  Password:        set
  Orders, delivery addresses and saved photo books refer to 8812

Sign-in identities for account 8812
  https://auth.photos.example   user-2048   linked 2026-09-28 18:12 UTC

Profile copied from https://auth.photos.example
  name          Robin Park
  email         [email protected]   (email_verified true)
  updated_at    1788220800           (2026-09-01 00:00 UTC)
  copied        2026-10-01 09:00 UTC

Three choices in that record matter.

The account has its own identifier. Orders, addresses, and saved photo books all refer to account 8812, never to user-2048. If the printer had used the subject as its account ID, your account would effectively belong to the photo service: a second provider would need a second account, and removing the photo sign-in would strand your orders. Identity rows are ways into an account, and the account outlives any one of them.

The profile is a copy, labeled with where it came from. You entered your display name and contact email when you registered. The photo service's name and email sit beside them as statements it made at one moment, and for a customer who signed up through the photo service, they supplied the starting values. Recording the source and the provider's updated_at lets the printer replace the copy when newer values arrive at a later sign-in, and keep apart what you typed, what it confirmed itself, and what it only received. The contact email shows why that matters. The printer sent its own confirmation link to [email protected] when you registered, and that confirmation, not the photo service's email_verified, is why it trusts the address for password resets. If the photo service later reports a different address, the printer can offer to use it, and confirm it before relying on it for anything that could hand over the account.

And the record leaves things out. It holds no ID token, no UserInfo response, and no access token. Those were evidence for one sign-in, and keeping them would only create something else to protect. The copied profile holds the claims the printer actually uses and nothing more.