Description
Follow-up from the #79 spike (see docs/spikes/issue-79-retry-session-multisig.md).
auth/challenge.ts's verifyAndGetToken exchanges a signature for a session token via the
backend's /auth/verify endpoint, but the response currently only returns { token } — no
expiry information. The SDK's session layer (src/auth/session.ts) now supports storing an
expiresAt alongside the token and exposes isSessionExpired(), but without a backend-supplied
TTL it can only apply a conservative client-side default (currently 15 minutes), which is a guess,
not a guarantee of the token's real lifetime.
Proposal
Extend the /auth/verify response with expiresIn (seconds) or expiresAt (UNIX ms), and update
verifyAndGetToken to pass it through to saveSession.
Acceptance Criteria
Description
Follow-up from the #79 spike (see
docs/spikes/issue-79-retry-session-multisig.md).auth/challenge.ts'sverifyAndGetTokenexchanges a signature for a session token via thebackend's
/auth/verifyendpoint, but the response currently only returns{ token }— noexpiry information. The SDK's session layer (
src/auth/session.ts) now supports storing anexpiresAtalongside the token and exposesisSessionExpired(), but without a backend-suppliedTTL it can only apply a conservative client-side default (currently 15 minutes), which is a guess,
not a guarantee of the token's real lifetime.
Proposal
Extend the
/auth/verifyresponse withexpiresIn(seconds) orexpiresAt(UNIX ms), and updateverifyAndGetTokento pass it through tosaveSession.Acceptance Criteria
/auth/verifyresponse includes a token expiry fieldverifyAndGetTokenin the SDK reads it and forwards it tosaveSession