Google sign-in, end to end
Google is the only way in. The consent screen authenticates the person, Google returns an assertion Connect verifies with Google rather than with the browser, and that assertion's stable subject identifier — not the email address on it — is what binds to a person here. A session follows, resolved to exactly one workspace. There is no password to be wrong.
The flow#
- Trigger — somebody opens the application without a valid session, or chooses to sign in as a different person.
- User or external event — the browser is handed to Google, which authenticates the person entirely on its own side. No password is entered into Connect, and none exists to enter.
- Authentication and workspace resolution — Google returns a signed assertion. Connect verifies it against Google directly rather than trusting what the browser presents about it.
- Ingest — the assertion is read for two things: the stable subject identifier that names this Google account for ever, and the profile details the consent covered.
- Canonical record — the subject is matched to a person. A first sign-in binds it; a later one recognises it. See Binding a Google identity to a person, end to end.
- Reasoning — none. Identity is matched, not inferred, and a near match is not a match.
- Knowledge, memory and rules — untouched by signing in. Who you are does not change what Connect knows.
- Autonomy and approval — not involved. Autonomy governs what Connect may do; signing in governs who you are.
- Action through a provider — the session is created and the browser is given an opaque cookie it cannot read from page scripts.
- Result — the session resolves to exactly one workspace, and every request afterwards is answered inside it.
- Relationship, timeline and memory — nothing about the workspace's people changes. A sign-in is not an event in anybody's history.
- Audit, usage and Needs You — the sign-in is recorded, including a replacement of an existing session on that browser.
| Stage | What you see | What changes | What can fail |
|---|---|---|---|
| Consent | Google's own screen, on Google's domain | Nothing in Connect yet | Consent declined, or the wrong Google account chosen |
| Verification | A brief return to the application | Nothing yet | An assertion Google will not confirm is refused outright |
| Binding | Either you are recognised, or you are new | A person record gains a subject on a first binding | A subject that does not match the one already bound — refused, not overwritten |
| Session | The application loads | A session exists; a previous one on this browser ends | Cookies blocked in the browser, which looks like a sign-in that does nothing |
| Workspace | Your own data | The session resolves to one workspace | A person with no workspace has nothing to open |
Why identity is not the email address#
An email address is a label a provider can reassign. A subject identifier is the provider's own permanent name for one account, and it is what Connect binds. The practical consequence is the useful one: somebody whose work address changes is still the same person here, with the same history, and somebody who is later given a departed colleague's address does not inherit their identity along with their mail.
Signing in and connecting a mailbox are different consents#
Signing in proves who you are. Connecting a mailbox asks Google for access to mail, which is a larger request with its own scopes and its own screen. They are deliberately separate: declining the second does not affect the first, and somebody can use Connect fully while a colleague owns the mail connection. Google's scopes for mail covers what the second consent actually asks for.
What can go wrong#
- The sign-in loops
- Cookies are blocked or discarded. The session is created and then thrown away by the browser, which looks like a refusal and is not.
- The wrong account
- A browser signed in to several Google accounts offers the last one used. Choosing deliberately is the fix; there is nothing to correct afterwards.
- Recognised, but nothing to open
- The identity is fine and no workspace has admitted this person yet. That is an invitation question, not a sign-in one.
- Refused with a mismatch
- The address is already bound to a different Google account. This is the protection working; see Binding a Google identity to a person.
One thing that is never the cause: a wrong password. There is no password sign-in here, so there is nothing to reset, nothing to leak in a breach somewhere else, and no reused credential to be found in one.
Questions#
Can a workspace add a password login for people who prefer one?
No. Password sign-in is deliberately not implemented, and that is a design decision rather than an unfinished feature. Every account is protected by whatever Google enforces for it, including the organisation's own rules.
Does Connect see my Google password?
No. Authentication happens entirely on Google's side, and what returns is an assertion about the account rather than any credential belonging to it. Nothing in Connect could reveal a password because nothing in Connect ever receives one.
What happens to my old session when I sign in as somebody else?
It ends, on that browser and only that browser. Other devices are untouched, which is worth knowing when you are relying on this to remove access rather than to switch accounts. See Establishing a session, end to end.