The Clerk session resource, with the fields listed in coverage.json.
The session token is deliberately absent: tokens are only available through
Clerk.requestToken, which round-trips to ClerkJS so the token is always
fresh. The session's user is not repeated here either; it is the sibling
user field of Clerk.SignedIn.
Minutes since the first and second authentication factors were verified,
as ClerkJS reports them for step-up checks. Nothing on the session when
ClerkJS has no age information.
Decode a Session from the JSON the shim sends.
{ "id": "sess_1"
, "status": "active"
, "expireAt": 1700003600000
, "abandonAt": 1702592000000
, "lastActiveAt": 1700000000000
, "createdAt": 1699990000000
, "updatedAt": 1700000000000
, "factorVerificationAge": { "firstFactorAge": 5, "secondFactorAge": -1 }
, "lastActiveOrganizationId": "org_1"
, "actor": null
, "tasks": []
, "currentTask": null
, "publicUserData": PublicUserData
}Timestamps arrive as epoch milliseconds. factorVerificationAge, actor,
lastActiveOrganizationId and currentTask accept null.
The active Clerk session.
statusis passed through as ClerkJS reports it (for example"active"), so a new status value never fails to decode.tasksholds the pending session task keys ("choose-organization","reset-password","setup-mfa") andcurrentTaskthe one ClerkJS is currently asking for.actoris set while an admin is impersonating the user.