Login - Jit4All

A user is signed into their Google account on their phone, visibly shown at the top of several Google apps. Opening a completely different, unrelated website on that same phone still shows that website asking the user to sign in from scratch, as if Google's own sign-in state meant nothing to it at all. The user is clearly, demonstrably signed into Google. Why doesn't that automatically sign them into this other site too?

Being signed into a Google account establishes the user's identity with Google itself, on that device or browser. It does not automatically share that identity with every other website a user happens to visit. A website only recognizes a Google identity if that specific website was deliberately built to request it, through Google's own sign-in system, and the user specifically agrees to share that identity with that particular site. Visiting an unrelated site that never made that specific request, and that the user never agreed to share anything with, has no way to know the user is signed into Google at all.

A Google account is a single identity a person can use across many different Google products, Gmail, YouTube, Drive, and others, by signing in once on a given device or browser.

Being signed into a Google account on a device establishes that identity for Google's own services on that device. It has no automatic effect on unrelated websites that have nothing to do with Google.

A website can choose to ask Google to confirm a visiting user's identity, but only if that website specifically implements this feature and the user specifically agrees, each time, to share their identity with that particular site.

A user can be signed into several different Google accounts on the same device at once, in different browser profiles or apps, which means being signed into Google does not even specify which one specific identity is currently active without more context.

Confirming identity through Google is a separate step from a website then deciding what that confirmed identity is allowed to do on that site. Google's part ends at confirming who is asking, and the website's own logic decides everything from there.

sub is a unique identifier for this specific Google account, intended to be the one stable value a website should actually use to recognize this user across visits, rather than relying on the more changeable email or name.

email and email_verified confirm the email address tied to this Google account, and specifically that Google itself has verified it belongs to a real, controlled mailbox, which is more assurance than a website simply asking a user to type an email address with no verification at all.

name is the display name associated with the account. Unlike sub, a name can be changed by the user, which is part of why it is a poor choice for actually identifying returning visitors compared to the stable identifier.

Nothing here describes what this user is allowed to do on the receiving website. That decision belongs entirely to the website's own code, using this confirmed identity as an input, not as an instruction.

This data reaches the website only after the user has explicitly agreed, through Google's own consent screen, to share it with this specific website, which is the deliberate step described in this lecture's intro that prevents this from happening automatically everywhere.

Google confirming who a user is answers one question, while what that specific website then allows that confirmed user to do is an entirely separate decision the website's own code makes. Receiving a confirmed identity is not, by itself, permission to do anything at all on that site.

A user changing their Google account's display name does not change their underlying account at all, but a website that mistakenly stored a name instead of the stable account identifier would lose track of which stored data belongs to that same returning user.

A user being signed into Google on their device does not pre-authorize any website to learn that identity. Each individual site has to implement its own request and receive its own explicit consent before Google will share anything with it.

A device with multiple Google accounts signed in across different apps or profiles means simply being signed into Google says nothing, on its own, about which specific account a given action or sign-in attempt is actually using.

A website asking a user to type their own email address, with no verification step, has no real confirmation that address is genuine or currently controlled by that person, while a verified email coming through Google sign-in carries Google's own confirmation that the address is real and currently theirs.

When an AI tool implements identity confirmation through a third party such as Google, three things are worth checking. First, does it use the stable account identifier, sub, rather than a changeable field like display name to recognize returning users. Second, does it correctly treat confirmed identity and granted site permissions as two separate concerns. Third, does it account for a user potentially having more than one account active, rather than assuming one single, unambiguous identity per device.

Sign into a Google account on one device, then visit an unrelated website with no Google sign-in feature, and confirm that site shows no awareness of the Google sign-in at all.

Look up what specific consent screen a user sees the first time a website requests their Google identity, and identify exactly what information that screen discloses is being shared.

Describe a realistic situation where having two Google accounts signed in on one device could cause confusion about which identity is currently being used.

Research what specific information a website is and is not given by default when a user signs in with Google, without that website requesting additional specific permissions.

Storing a user's changeable display name, instead of their stable account identifier, as the way to recognize them on return visits.

You can now explain why being signed into Google does not automatically sign a user into unrelated websites, and identify the specific consent step that has to happen before any website learns a user's Google identity. You can also explain why a stable account identifier, not a display name, is the correct way for a website to recognize a returning, Google-identified user.