Interface: SessionPayload
Defined in: auth-core/src/index.ts:82 (opens in a new tab)
ExtendsLink to this section
unknown
PropertiesLink to this section
| Property | Type | Description | Defined in |
|---|---|---|---|
aud? | string | string[] | Who the token is for. Absent on a family session (the oc_session cookie on *.ochk.io). On a token from the ochk.app sign-in popup it is one string: the origin of the page that opened the popup. Verify with audience set to your own origin. | auth-core/src/index.ts:90 (opens in a new tab) |
did_oc | string | Opaque public-facing identifier · did:oc:<32-hex>. The sole canonical user identifier post auth-refactor. Stable across linking events. Per AUTH-REFACTOR-PLAN.md §2.1. | auth-core/src/index.ts:109 (opens in a new tab) |
display_identity? | DisplayIdentity | null | The identity the user has chosen to show in their account badge — the collapsed label every family site (and any integrator) renders instead of the raw did:oc. Baked into the JWT so the choice is consistent across every .ochk.io subdomain with no round-trip, the same posture as name / npub. Re-resolved by the auth host on every mint: an explicit user promotion wins; absent that, it defaults to the account's sign-in identity (BIP-322 accounts → their Bitcoin address, federation accounts → their email). Absent / null on tokens minted before this field shipped — consumers fall back to the did_oc. Read it safely with resolveDisplayIdentity(). | auth-core/src/index.ts:207 (opens in a new tab) |
exp? | number | Unix seconds after which the token no longer verifies. For a popup token it is the earlier of the ochk.io session's expiry and iat + 30 days. It is never refreshed: when it passes, the person signs in again. | auth-core/src/index.ts:103 (opens in a new tab) |
home_federation? | string | null | Deprecated No longer minted. Where a person's sats sit is me.ochk.io's to say, per federation, from its own ledger (/api/me/balance). | auth-core/src/index.ts:124 (opens in a new tab) |
iat? | number | Unix seconds when this token was minted. For a popup token that is the end of the popup's sign-in, not when the person's ochk.io session began. Keep it with rh and aud: a cutoff on the list of ended sessions is compared with it. | auth-core/src/index.ts:97 (opens in a new tab) |
is_owner? | boolean | Optional best-effort owner flag · set by the auth host at signin time when the new did_oc matches OWNER_OC_ADDRESSES. Surfaced through to clients via useOcSession().account.isOwner so the family-switcher and other low-stakes UX can render owner-only affordances (e.g. an analytics.ochk.io entry). NOT A SECURITY BOUNDARY. Sensitive surfaces still re-check the live OWNER_OC_ADDRESSES env against session.did_oc on every request (analytics.ochk.io's requireOwner does this). If an owner is removed from the env, their JWT may still carry is_owner: true for up to 30 days — the UX hint goes stale, but every gated action they attempt re-fails server-side. Treat absence as false. Set only on first signin or re-issue; never mutated mid-session. | auth-core/src/index.ts:192 (opens in a new tab) |
jti | string | auth-core/src/index.ts:110 (opens in a new tab) | |
merged_from? | string[] | Historical did_ocs consolidated INTO this account via the /api/auth/link/btc transfer-under-dual-proof flow. Consumers that aggregate per-user data should union queries across [did_oc, ...merged_from]. Absent / empty means "no absorbed accounts." Order is not significant. | auth-core/src/index.ts:144 (opens in a new tab) |
name? | string | null | Optional display name set by the user via the auth host's profile surface. When present, consumer subdomains can render it in their header chip without a network round-trip. Re-minted on signin and whenever the user updates their profile. | auth-core/src/index.ts:117 (opens in a new tab) |
npub? | string | null | Optional Nostr npub set by the user. Same lifecycle as name. | auth-core/src/index.ts:119 (opens in a new tab) |
oc_bond? | BondClaim | Present when the account is backed by a bond. Absent means no bond, not a failed check. Read it with readBondClaim() / bondMeets(). | auth-core/src/index.ts:212 (opens in a new tab) |
rh? | string | The token's revocation handle on its audience's list of ended sessions, on every token the ochk.app sign-in popup issues: one handle per account and audience. A token that carries one verifies only with a single string aud. Keep it with aud and iat to check "sign out everywhere". | auth-core/src/index.ts:151 (opens in a new tab) |
signing_method? | "fedimint_threshold" | "fedimint_client" | "bip322" | null | Whether the account signs with its own Bitcoin key. The auth host derives it at every mint from the account's verified linked identities; no one can set it. - 'bip322' — a BIP-322-verified Bitcoin address is linked. - 'fedimint_threshold' — none is, so the account holds no key here. - 'fedimint_client' — reserved; never minted. It says who holds the signing key, never who holds the sats. | auth-core/src/index.ts:136 (opens in a new tab) |
step_up_at? | number | Unix seconds when the user last successfully completed a WebAuthn step-up assertion on the auth host. Consumer subdomains gate sensitive actions on (now - step_up_at) < their_window — typically 5 minutes. Absent on JWTs minted before WebAuthn shipped, or on tokens minted by ordinary signin (only set by /api/auth/webauthn/assertion/verify on success). Use verifyStepUpClaim() to read it safely. | auth-core/src/index.ts:161 (opens in a new tab) |
sub | string | auth-core/src/index.ts:83 (opens in a new tab) | |
sudo_at? | number | Unix seconds when the user last successfully completed an inline sudo-mode re-authentication on the auth host (email-OTP for email-primary identities, BIP-322 challenge for btc-primary identities). Gates auth-graph-mutating operations — register an additional WebAuthn credential, revoke one, link a new identity, change recovery method — without forcing a full sign-out/sign-in. Same shape and freshness window posture as step_up_at; the two are independent claims (sudo proves "you typed your password again," step-up proves "you tapped your hardware key"). Read it with verifySudoClaim(). | auth-core/src/index.ts:174 (opens in a new tab) |