Accounts and sign-in

#There is no password

TableCore accounts are passwordless. There is no password field anywhere, and that is not an oversight — you are being told because people trained to look for one assume something is broken.

• Sign in with Google, GitHub or Microsoft.
• TableCore never accepts or stores an account password.
• Provider access tokens are used for the moment of sign-in and are not persisted.
• Only hashes of random tokens are stored on the server side; sign-in attempts, links and sessions are single-use or revocable and all have a time limit.

If the same e-mail address arrives from a different provider, the two are not joined automatically. Linking accounts is a deliberate flow that does not exist yet, so for now they stay separate.

#Signing in on the website

Go to Sign in and choose a provider. You come back to the account panel at /account.

#Signing in on the desktop

The desktop application never renders a password field and never asks for your provider credentials. It hands the whole thing to your normal browser.

1. Open the account from the icon in the title bar, next to settings, or from File → TableCore account.
2. Choose to continue in the browser. TableCore generates a state value and a PKCE challenge, keeps the short-lived verifier in the OS credential store, and opens the approval page in your system browser.
3. Approve the request in the browser. The page issues one 12-character code.
4. The application picks it up automatically, or you paste it in.

#How the code comes back

On Windows, TableCore registers the tablecore://auth/callback protocol for the current user. The callback carries only the code and the state — your account, the refresh token and the licence state come back over a separate HTTPS request after the PKCE check succeeds. Nothing sensitive travels through the protocol handler.

Every platform always has the manual code, and it is not a fallback in the sense of a degraded path — it is the primary mechanism on macOS and Linux, which have no installer to register a protocol with yet, and it is what you use on Windows when the protocol prompt is blocked. The code is short-lived, usable once, and bound to that one sign-in request.

#The desktop session

The refresh token lives only in the operating system credential store — never in a settings file.

• It is rotated every time the session is renewed.
• Re-using an old one revokes the whole family. That is the standard defence against a stolen token, and it means a token copied off a machine stops working the moment the real session refreshes.
• Signing out invalidates the token at the API first, and removes it locally only after that succeeds.
• You can see and revoke active desktop sessions from the account panel on the website, which is what to do if you lose a machine.

Without a signed-in account, TableCore keeps working on the Free plan. Not needing an account is not the same as being licensed for Free: that depends on who you are, and Plans and Pro features says who qualifies.

#The account indicator

The account icon in the title bar has three states: signed out, Free and Pro.

No session beats a stored level: a level with no session is not an entitlement, and announcing Pro to somebody who is not signed in would be a claim by the interface rather than by the account.

The indicator shows exactly the same gate that decides whether a Pro action runs, so it tells the truth about what the application will let you do — and, like that gate, it is not a security boundary.

#What the account service never sees

Your database credentials. The desktop application talks to your MongoDB servers directly and to the account service about your account; those are two different conversations and the second one has nothing to say about the first. See Credentials and secrets.

#Erasing the account

Settings → Erase this account, in the account panel on the website. It is a control, not a request you wait on: the session you are already signed in with is the verification, you type your own e-mail address to confirm, and the deletion runs immediately.

There is no password to re-enter and no code sent by e-mail, because there is no password and production e-mail is not in place. Asking for a second factor here would mean inventing one and then storing it, which is the opposite of what this does.

What goes: the account and its e-mail address, the connected provider identities, every browser session, every authorised desktop installation, your preferences, your support requests with the internal notes on them, any manual licence grant, any one-time sign-in link still pending for your address, and the subscription record.

That last one is held by address rather than by account — a link is requested before any account exists — so it is the one row erasure has to find without an account id to follow. It is deleted by the request, not left for the daily cleanup.

What stays, and the confirmation says so rather than keeping it quietly:

• The payment provider's own invoice and tax records. They are its copy, kept under its own obligations.
• The audit entries and the record of the erasure. Append-only by database rule, and holding only the opaque account identifier — never the address, the provider identity or the content of a request. Once nothing maps that identifier to a person, it names nobody.
• Crash reports you sent. They arrive with no account attached and record only whether somebody was signed in, so nothing can find them by account. They expire 180 days after they arrive.
• A licence file already on a device. It is signed, it is yours, and it keeps working until it expires; the application then falls back to Free. Erasure removes the credentials that would issue a new one.
• The platform's own recovery history, for up to 7 days, and its request logs for 3.

You are given a reference for the record of the request. Keep it: everything that mapped the account to you is gone, so quoting it is the only way the record can be found again.

An administrator can run exactly the same operation, with a stated reason in the audit log, for a request that arrives by e-mail instead. Section 7 of the Privacy Policy states the same periods.

#Next

• Plans and Pro features — what is gated.
• Offline and entitlements — what happens on a plane.