Unispec ID
Sign-in, sessions, passkeys and TOTP for your users — the CIAM surface of the Unispec agent-IAM platform.
Unispec ID is the identity product of the Unispec platform: human sign-in today (password, Google, passkeys, TOTP), and — the part no classic auth provider ships — agents as first-class principals with delegation chains, scoped short-lived credentials and a kill switch, arriving with the delegation API.
Status: the human CIAM surface is SDK-first. You integrate with
@unispec-ai/id and bring your own UI; hosted auth pages
(redirect-style, Auth0-Universal-Login-like) are on the roadmap.
Sign-in methods
| Method | How | Notes |
|---|---|---|
| Password | auth.signUp / auth.signIn({method:"password"}) | Email is the identifier |
auth.signInWithGoogle({returnTo}) | Redirect round-trip; browser only | |
| Passkey | auth.signIn({method:"passkey"}), settings.addPasskey() | See the origin note below |
| TOTP | settings.enableTotp() / verifyTotp | Second factor; sessions step up to aal2 |
Sessions: browser vs server
- Browser — sign-in sets a session cookie on the Unispec ID host; the SDK
sends credentialed requests and exposes
getSession()/onAuthStateChanged(). - Server — the SDK uses token-mode flows: sign-in returns a session token
(
client.sessionToken), sent asX-Session-Token. Verify inbound callers withclient.verifySession({token})(or{cookie}for forwarded browser requests).
Recommended integration: first-party proxy
Browsers increasingly refuse third-party cookies, so the reliable pattern is
to serve the ID API from your own origin: rewrite /v1/id/* to
https://id.unispec.ai/v1/id/* in your dev server, framework or edge config,
and create the client with a relative base:
const id = createIdClient({ baseUrl: "/v1/id" });async rewrites() {
return [{ source: "/v1/id/:path*", destination: "https://id.unispec.ai/v1/id/:path*" }];
}Calling https://id.unispec.ai directly with CORS also works (your origin
must be on the deployment's allowlist) and is fine for server-side use and
quick experiments.
Passkeys and origins
WebAuthn binds every passkey ceremony to the deployment's relying-party
domain (rp.id). Ceremonies therefore run on pages under that domain — a
third-party site cannot trigger them, by design. Practically: develop and
test passkeys against the local stack (its rp.id is localhost), and
expect production passkey sign-in to light up with the hosted auth pages.
Password, Google and TOTP have no such restriction.