# 18.15 The sign-in server you run (/building-ai-workers/securing-connectors/the-sign-in-server-you-run) --- type: Document title: "18.15 The sign-in server you run" description: "What the sign-in server stores and never stores, key rotation with an overlap, refresh chains, and staging kept apart." status: stable order: 318.15 ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-11-02T18:20:57Z chapter: "18" part: III expert_status: builder-only concepts: [ "18.15" ] objectives: - { id: CCDV-F.D7.S4, label: supporting } - { id: CCDV-F.D2.S2, label: supporting } last_verified: 2026-11-02 sources: - id: oauth21 title: "OAuth 2.1, draft 17 (IETF, accessed 2026-11-02)" resource: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/ - id: mcp-authorization title: "Authorization, MCP specification 2026-07-28 (MCP, accessed 2026-11-02)" resource: https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization generated: at: 2026-11-02T18:20:57Z by: process:panaversity trust_tier: unverified build_id: sha256:e1fbcb7d9a8f8b9b7cb96875022325c02c9ba4be94cef13b301cbd39a9edad85 dirty: true ksor_version: 0.0.60 --- **In everyday life.** A building's security office keeps the visitor log, the badge records and the master key cabinet. It does not keep the tenants' files. If someone broke into the security office, they would learn who works where, but they would not walk out with anyone's accounts. And the master keys are changed on a schedule, with the old ones still working for a short overlap, so nobody is locked out on the morning of the change. **What you will learn.** What the sign-in server stores and never stores, and how to replace its keys and keep it safe. **Why it matters.** Every connector trusts it, so a mistake here reaches every company at once. **One change, start to finish.** Brightline replaces its token signing key on the first of each month. Remember the wax seal from [18.6](a-token-made-for-one-door.md): the private signing key is the stamp, and the public keys are the posted pictures. 1. **The sign-in server makes a new stamp,** a new private signing key and its public key. It posts the new picture and starts sealing new tokens with the new stamp at the same moment. 2. **It keeps posting the old picture** beside the new one. 3. **The connector meets a token sealed with the new stamp.** Each token's label section carries a short ID naming the stamp that sealed it. The connector does not have that picture yet, so it fetches the public keys again, finds it, and accepts the token. It fetches again for an unknown stamp at most every 30 seconds, and every few minutes anyway. So a connector that fetched just before the change refuses the first new tokens for up to 30 seconds, and the app tries again. That short wait is the only cost of a scheduled change. 4. **Tokens sealed with the old stamp keep working** until they run out, within 10 minutes. After an overlap, a set time when both are accepted (one day at Brightline), the old picture is taken down. Nobody was signed out, and no setting changed in any AI app. ### What is yours to keep safe? The sign-in server is a program you run, so keeping it safe is your job. ### What does it store? It keeps these in its own database: people and their password hashes, sessions, companies and memberships, the apps it knows, each consent record, refresh tokens (stored only as hashes, because the server only compares them, as with passwords, and never needs the original), and its signing keys. The private halves of the signing keys are **encrypted**: scrambled so that only someone holding the right secret can unscramble them. That is the difference from a password hash, which can never be turned back. ### What does it never store? Business data. Invoices, vendors and policies live with the connector, and from Chapter 19 in a separate database. Keeping the two apart means a mistake in one does not expose the other, each can be backed up on its own, and the people who may change one need not be able to read the other. ### How is it kept safe? - **Rotation: replacing a signing key on a schedule,** with an overlap, as in the steps above. If a private signing key ever leaks, replace it at once and take the old picture down immediately, with no overlap. Connectors keep the old picture for up to 10 minutes, so restart them to drop it at once. Every token sealed with the old stamp then stops working. Apps get new tokens with their refresh tokens, which are not sealed with the stamp, or people sign in again. If the secret that encrypts the private keys may have leaked too, replace it, and replace the stamp again. That is the price of a leak, and it is why the private key never leaves the sign-in server. - **Refresh tokens are replaced on every use.** An app gets one only if it asks for it. A refresh token lasts much longer than a sign-in token, so it is the more valuable thing to steal. So each time an app uses one, the sign-in server returns a new one and retires the old one. Each new refresh token is linked to the one before it, back to the sign-in that started them, like links in a chain. Why that matters: 1. A thief copies Ana's refresh token and uses it first, getting a fresh pair. 2. Later, Ana's app uses its own copy, which is now retired. 3. The sign-in server sees a retired token come back, so it knows one of the two is a copy. It cancels every refresh token that app holds for Ana, for every company, not only this chain. 4. The thief can get no fresh token, and the sign-in token in hand runs out within 10 minutes. Ana signs in again, which is the safe outcome. - **Staging and production are separate.** Each has its own sign-in server, its own database and its own keys. A staging token names staging's sign-in server and staging's connector, so production refuses it twice over: once for the wrong issuer, once for the wrong audience. - **Every change through review.** Tables change only through migrations ([F2](field-guide-securing-connectors.md#f2-relational-databases-and-d1-from-zero)), and code only through pull requests, as for the connector. **At work.** Brightline's first key rotation happens during a working day. The builder watches the connector's logs: a short burst of "unknown key, fetching keys", then nothing unusual. In `docs/deploy.md`, the runbook, its step-by-step notes, gains "Rotate the signing key" and "If the signing key leaks", side by side, so the difference is clear. **The operating rule:** the sign-in server holds who people are and what they may do, never business data. Replace its signing keys on a schedule with an overlap, and at once without one if a key leaks. Replace refresh tokens on every use. Keep staging and production fully apart. *The standards behind this concept: OAuth 2.1's rules for refresh tokens,[^oauth21] which the MCP specification requires for apps that have no client secret (an app's own password, which apps on your computer cannot keep hidden), such as coding agents on your computer.[^mcp-authorization]* ![The sign-in server's tables as a group of cards: user, account, session, organization, member, app clients, consent records, refresh tokens, signing keys. Beside them, a crossed-out box: business data, invoices, vendors, policies, never here. Below, a key rotation timeline: key 1 seals, then key 2 seals while key 1's public key is still posted, then key 1 is taken down after the overlap. A connector checks tokens from both periods.](img/chapter-18-auth-server.png) *Figure 18.18. What the sign-in server stores, what it never stores, and how a signing key is replaced without signing anyone out.* [^oauth21]: OAuth 2.1, draft 17, IETF. [^mcp-authorization]: Authorization, MCP specification 2026-07-28, MCP.