Authentication, identity and tenancy
These pages are about who you are to the hub: how you sign in, what the hub knows about you, and how it keeps your data apart from everyone else's. You do not need them to use the hub. They explain what happens behind the sign-in page and underneath every request.
Topics
- Signing in: the sign-in server, and the ways in it offers.
- One session across sites: why signing in on one site signs you in on all of them.
- Identity: the record the hub holds for each person.
- Addresses: the name everything in the hub is reached by.
- The principal: who a request is made as.
- Authorization: the layers that decide what you may do.
- Tenancy: how the database keeps one owner's data from another's.
Signing in, sessions and addresses are reachable by a program as well as from the page.
Signing in is the auth routes, under /auth/oidc. Hydra sends the browser to the login bridge, which forwards it to the hub's login page. The page posts back, and the backend verifies the sign-in and accepts Hydra's challenge. Consent, sign-up and the second factor each have a call beside it, and a context call tells the page what the challenge needs. Passkeys and authenticator apps are managed through the account routes.
Sessions across sites are the oauth routes. A sign-in preflight tells a sister site whether you are signed in, and it fails closed. A site's login reads only ?return_to=; ?return= is the relay between the hub and the sister site.
Addresses are resolved through the registry routes.
Over MCP, an agent authenticates with a personal API token, and the token's scope decides which tools it gets.
The full list of routes, with each one's parameters, body and responses, is the REST reference on the help site. The tools an agent gets are listed in the MCP reference.
One place for every account. The sign-in server is run headless so that the account, the login page and the consent page are all the hub's own, and a developer and an end user are the same kind of record.
The realm is worked out, never declared. A client that could say which realm it belongs to could claim a tenancy that suits it.
The sign-in check fails closed. Failing closed costs a visitor the avatar in the header. Failing open would cost them the page.
The sites a sign-in may return to come from the registry. A list kept by hand drifts, and a missing entry is a silent outage on one site.
One function establishes every principal. Every credential ends in the same function, so usage, rate limits and the audit record all see one shape.
The database enforces tenancy. A handler that forgets to filter still cannot read another owner's rows, because the rule is forced on the account the application connects as.
Refuse, never rename. A silently renamed object is worse than a refused move, because the owner finds out later or not at all.