Documentation · Releases · Arachne

Arachne — OIDC/SSO identity provider

v.Chronos.Marsyas.0 — legacy v.H.1.23

One identity fabric, many threads: the hub signs who you are once, and every consumer verifies that proof against published keys — no consumer ever handles a hub password.

Arachne.0 turns the hub into a central OpenID Connect / SSO identity provider. A consumer application (Pythia is the first) sends a user to the hub to log in; the hub returns a short-lived authorization code, the consumer exchanges it for an RS256-signed id_token, and the consumer verifies that token against the hub's published JWKS — the consumer never sees a hub password and never re-implements authentication. Tokens carry an opaque, stable subject the consumer keys its user record on (never the mutable email) and a roles claim carrying the ancient-admin gate. The whole surface is hardened: exact redirect_uri binding, S256 PKCE on both ends, atomic single-use authorization codes (a concurrent double-redemption yields exactly one token), a token-type-confusion guard, per-origin CORS with a rate limiter and a break-glass disable, and a discovery document so consumers feature-detect rather than hardcode. Introspection is intentionally absent — verification is done against the published keys.

Why “Arachne”

Arachne was the mortal weaver whose skill rivalled Athena’s — she wove a single flawless tapestry that threaded many separate strands into one continuous fabric.

For this release, “Arachne” names the shape of the new identity layer: the hub weaves many separate consumer applications into one central identity fabric. Each consumer is a thread — Pythia is the first, wired end-to-end — and every thread verifies the same signed proof of who a user is against the same published keys, instead of each app re-implementing authentication against the hub.

What changed for the operator

  • The hub is now an OpenID Connect provider. It signs RS256 id_tokens, publishes its verification keys at a JWKS endpoint, and serves a /.well-known/openid-configuration discovery document so a consumer can wire itself up from one URL.
  • Ancient-gated client registration.An Ancient-only admin UI registers a consumer application: it mints a confidential client secret (stored only as a salted hash, shown once), pins the consumer’s exact redirect URI, and sets its allowed scopes.
  • Stable, opaque subjects.Every consumer keys its local user record on the token’s sub— an opaque, stable identifier that never changes even if the user’s email does — never on the mutable email address.
  • The ancient-admin gate travels with the token.The id_token’s rolesclaim carries the caller’s role set; a consumer gates its admin surface with roles.includes("ancient"), so ancient status is proven cryptographically, not re-derived.
  • Hardened by construction. S256 PKCE on both ends, exact redirect_uri binding, atomic single-use authorization codes (a concurrent double-redemption yields exactly one token), a token-type-confusion guard (an id_token is rejected as a bearer token), per-origin CORS with a rate limiter, and a break-glass disable.
  • Pythia wired end-to-end. Pythia is registered as a confidential, server-to-server client (no browser CORS origin) and driven through the full flow — login, authorization code, id_token, JWKS verification, ancient-admin gate — as the proof the provider works against a real consumer.

Integrating a consumer

The full, living integration guide — how to register a client, the exact authorize → callback → token flow with concrete URLs, and a copy-paste Node verification snippet embodying every security pin (verify with algorithms: ['RS256'] + a pinned issuer and audience, reject alg:none/HMAC and cross-client audiences, always verify a random nonce, key on sub, treat roles as a set) — is published as a public docs chapter:

SSO integration how-to →

Operator notes

  • The client secret is shown once.A confidential client’s secret is delivered at registration and stored only as a salted hash — it is never re-derivable from the hub. Record it when you register the consumer.
  • No token introspection endpoint. Verification is done against the published JWKS, not by calling back to the hub. Consumers feature-detect the available capabilities from the discovery document rather than hardcoding grant or scope sets.
  • Registration is Ancient-only. Only an Ancient admin can register or disable a consumer client, and every registration is audit-logged.