OpenID Connect
OAuth answers *may this application do this*. OpenID Connect adds the missing question — *who is this person* — by returning a signed ID token alongside the access token. Connect signs people in with Google, which is an OpenID Connect provider, and there is no other way in. Identity is where a session starts; it is not where any permission is decided.
What the extra token contains#
An ID token is a signed assertion about the person who just authenticated, in a format the relying application can verify without asking the provider anything further. Its claims are small and specific.
| Claim | Meaning | Why it matters |
|---|---|---|
sub | The provider's stable identifier for this person | The only claim safe to key an account on — it does not change |
email, email_verified | The address, and whether the provider vouched for it | Convenient for display, unreliable as a key: addresses get reassigned and changed |
iss, aud | Who issued the token and who it was issued for | A token minted for another application is not yours to accept |
exp, iat | Expiry and issue time | An assertion about a moment, not a standing fact |
nonce | A value the application put into the request | Ties the token to the sign-in attempt that asked for it |
Every one of those has to be checked. A relying party that reads claims without verifying the signature, the issuer, the audience and the expiry is accepting a document anybody could have written — which is the single most common way an identity integration goes wrong.
Why the email is not the account#
Keying an account on an email address feels natural and fails in three ordinary ways: a person changes their address and loses their history; an organisation reassigns a departed employee's address and the new holder inherits an account; two providers assert the same address and each believes it owns it. sub has none of those problems because it means nothing outside the issuer that minted it.
The same reasoning appears elsewhere in Connect for the same reason. A Person is a record; an address on a channel is an Identity that resolves to that Person. One human with a work address, a personal address, a WhatsApp number and a phone number is one relationship, not four, and the address is never the thing being identified.
Does Connect use OpenID Connect?#
Used, as the only sign-in. Signing in to Connect means signing in with Google. There is no password login, no magic link and no local account: password_sign_in is recorded as not implemented, deliberately. If your organisation cannot use Google identities, Connect has no alternative route to offer, and that is a fact to establish before an evaluation rather than after one.
What the identity does not do is grant access to anything. Signing in establishes who you are; the workspace you may act in is resolved separately by workspace_kernel, and every request after that is filtered three more times — the customer_safe allowlist in the middleware, the SQLAlchemy workspace kernel, and row-level security in PostgreSQL. A valid identity with no workspace is a signed-in person who can see nothing, which is the correct outcome and not a fault.
Questions#
Can I use my own identity provider?
Not today. Google is the identity provider Connect signs in with, and nothing on this page should be read as describing a configurable one. It is the right question to ask before adopting, because there is no fallback path.
Is the ID token used to call the API?
No, and it should never be. An ID token is an assertion about a sign-in, not a credential for an API. A person's browser carries a session; a machine uses an integration key. Sending an identity token as an API bearer is a category error that some services accept and none should.
What happens if the same person signs in on a second browser?
Both sessions exist. Signing in as somebody else on one browser ends the session it replaced on that browser only — never that person's other devices, because sharing one machine should not sign somebody out of their phone.