User Hub

Dashboard

One canonical user store, fed by the connected IdPs. Tools never talk to Okta again — they ask the hub.

Connections

–

Users

All identities across the connected IdPs, with every profile attribute. Click a row for details and the kill switch.

Search

Connection

Per page

active only

	Email	Name	Source	Status	Access	Updated

IdP connections

Each connection is one IdP org. Pull sync via API token, plus an Okta Event Hook for instant deprovisioning.

Add connection

Name

Type

Base URL

OAuth client ID

Client secret (optional)

Okta setup (private_key_jwt, no SSWS tokens, no secrets): (1) Admin Console → Applications → Create App Integration → API Services → copy the client ID here and Add. (2) The hub then shows this connection's public key (JWK) — in the Okta app under General → Client Credentials switch to "Public key / Private key", Add key, paste the JWK, Save. Keep DPoP off. (3) Okta API Scopes tab → Grant okta.users.read — nothing else. (4) Admin roles tab → assign Read-only Administrator. Then Test.

Connectors

Tools that consume users from the hub. Registered canisters may call checkAccess(email); the push contract below is what every future tool ships by default.

Registered tools

Name	Canister	Note	Sources

Sources = which IdP connections this tool may see (directory, tickets, checkAccess). Default: all. Connection IDs are shown on the IdP connections page (#1, #2, …).

Name

Backend canister id

Note

Connector contract (Phase 2 push)

Every new tool includes this candid by default; the hub is its only caller. Until push ships, tools gate sessions with checkAccess:

// implemented by each tool's backend type ConnectorUser = record { email : text; displayName : text; firstName : text; lastName : text; active : bool; source : text; externalId : text; attributes : vec record { text; text }; }; service Connector : { hub_upsert : (vec ConnectorUser) -> (nat); hub_deactivate : (vec text) -> (nat); // emails hub_ping : () -> (text) query; } // provided by the hub (this canister) — call on login/session checks: checkAccess : (email : text) -> (variant { active; inactive; unknown }) query

Journal

Syncs, event hooks, admin actions — newest first.

–

How it works

The hub is one canister pair on DFINITY's dedicated cloud engine. It syncs the IdP directories into a canonical user store, signs users in via OIDC, and is the single access authority for the in-house tools.

Architecture

Data flows

1 · Pull sync (hourly, configurable). The hub mints a 5-minute ES256 client-assertion JWT (RFC 7523) per Okta org, exchanges it for a Bearer token at the org's /oauth2/v1/token (scope okta.users.read only), and pages GET /api/v1/users. Read-only: the hub never writes to any IdP. Users missing from a full pull are marked deprovisioned.
2 · Event hooks (seconds). Okta POSTs lifecycle events (deactivate / suspend / unsuspend / activate / delete) to a per-connection URL carrying a 256-bit random path secret. Deactivations apply immediately.
3 · SSO login (OIDC Authorization Code + PKCE). The browser redirects to the IdP; the returned code goes to the hub backend, which exchanges it DIRECTLY at the provider's token endpoint over TLS. Because the id_token comes from that direct exchange (not from the browser), forged tokens are not possible; the hub checks iss / aud / exp, then matches the email claim against the user store. Only synced, ACTIVE users get a session (8 h). Every session check re-validates the live status — deactivation kills sessions instantly.
4 · Access gate. Tools call checkAccess(email) (restricted to registered connector canisters + admins) on login/session validation. The hub is the single access authority; a user's Internet Identity may continue to exist, but no connected tool lets them in once the hub says inactive.

Keys & secrets

Material	Where	Exposure
ES256 signing keys (sync auth)	generated in-canister from IC randomness	never leave the canister; Okta gets the public JWK only; rotatable per click
Okta side	API Services app per org	least privilege: scope okta.users.read + Read-only Administrator role; no SSWS tokens, no shared secrets
Event-hook secrets	256-bit raw_rand, in the hook URL path	known to Okta admins only; rotatable; bad-secret calls rejected with 403
SSO session tokens	512-bit raw_rand, stored server-side	bearer token in the user's browser (localStorage); 8 h TTL; server-side revocation on logout/deactivation
Google client secret	canister state, write-only (masked in every view)	required by Google web clients; Okta SSO uses PKCE without any secret

Trust model & accepted risks

Engine subnet nodes. The hub runs on DFINITY's dedicated cloud engine (7-node CloudEngine subnet). HTTPS outcalls for token exchanges run non-replicated (is_replicated=false) — REQUIRED, because auth codes and token mints are single-use and would otherwise be sent once per replica. Consequence: a malicious node on our own engine could in principle forge an outcall response. This is the platform trust base of everything on the engine, not specific to this app.
id_token verification. Claims are checked (iss/aud/exp) but JWKS signatures are not re-verified locally — unnecessary because the token arrives via the backend's own TLS exchange with the provider, never via the browser. PKCE prevents code substitution.
Canister state. Node operators of the engine subnet can technically read canister memory (standard IC property). Stored there: user directory data, session tokens, one Google secret, signing keys. Same trust base as above; vetKD-based encryption is the documented upgrade path if required.

Hardening in place

· Every admin method asserts an allowlist (II principal or controller); connector queries assert registered canister IDs; user endpoints are session-token based.
· ssoExchange: input size caps, https-only redirect URI, global rate limit (60 attempts / 5 min) — protects the IdPs' rate limits from anonymous floods.
· Sync reentrancy guard per connection, self-expiring after 15 min (no deadlock after a trapped run).
· TOCTOU guard: a deactivation arriving DURING a sync wins over the stale page data of that sync.
· Denied logins (unknown / inactive email) and all admin actions land in the journal (capped, admin-only).
· Frontend loads its crypto/agent bundle exclusively from this asset canister — no CDN fallback.
· The hub is read-only towards the IdPs; deprovisioning flows one way (IdP → hub → tools).

Settings

Auto-sync

Pull interval

Deactivations do NOT wait for this interval: Okta Event Hooks apply them the moment Okta fires, and tools calling checkAccess() are blocked instantly either way.

App onboarding playbook

The standard procedure for connecting ANY app to the hub — same policies every time. A machine-readable copy exists as the Claude skill user-hub-app-onboarding, so the assistant applies identical steps on every integration.

1 REGISTER Connectors → add the app's BACKEND canister id. This unlocks: redeemTicket, connectorDirectory, connectorAvatar, checkAccess for that canister. 2 SCOPE Set sources if the app must not see every IdP (default: all connections). 3 TILE Settings → App tiles → name + frontend URL. Tile id must match the app's HUB_JUMP_ID constant. 4 APP SIDE The app implements, in this order: - ticket login: #uht fragment → its backend calls redeemTicket → own session (8-12 h, raw_rand token) - directory: pull connectorDirectory on a 15-min timer; show source org next to duplicate names - contract: hub_deactivate([email]) — drop users INSTANTLY, keep their data as archive (Slack model); hub_upsert, hub_ping (caller = hub canister only) - live gate: every session check re-validates the user against the directory (inactive = session dies) - avatars: proxy connectorAvatar with a short cache; initials as fallback 5 POLICIES no own login lane for internal users · guests may keep link-based access · changelog entry per release · stable vars append-only · rate-limit anonymous calls 6 VERIFY portal tile → app opens signed-in · kill switch in the hub removes the user from the app within seconds · denied jumps land in the journal

App tiles (portal)

Tools users can jump to from the portal. The jump mints a one-time 90-second ticket that only the tool's REGISTERED backend canister can redeem — register it under Connectors first.

Name	URL	Note

Name

URL

Note

SSO login providers

Synced users sign in here directly via OIDC (no Internet Identity). Redirect URI to register at the provider:

Name	Type	Client ID	Status

Name (button label)

Type

Issuer (Okta only)

Client ID

Client secret (Google only)

Okta: Applications → Create App Integration → OIDC → Single-Page Application; Grant type Authorization Code (PKCE); Sign-in redirect URI = the URI above; assign the users/groups who may sign in. Google: Cloud Console → OAuth client (Web application) → same redirect URI. Who can actually log in is decided by the hub either way: only synced, ACTIVE users pass.

Admins

Name	Principal

Name

Principal

Your workspace

Dashboard

Connections

Users

IdP connections

Add connection

Connectors

Registered tools

Connector contract (Phase 2 push)

Journal

How it works

Architecture

Data flows

Keys & secrets

Trust model & accepted risks

Hardening in place

Settings

Auto-sync

App onboarding playbook

App tiles (portal)

SSO login providers

Admins

–