Store interface for refresh tokens.
Implementations must track each jti so the service can rotate (revoke the presented token, issue a new pair) and revoke (logout). All methods are async so remote backends (e.g. a future Redis store) can implement the interface without a breaking change.
save(record: RefreshTokenRecord): Promise<void>
Store or update a refresh token record.
get(jti: string): Promise<RefreshTokenRecord | null>
Retrieve a record by jti; returns null if missing or expired. A revoked record is still returned so the caller can distinguish replay of a rotated token from an unknown token.
revoke(jti: string): Promise<void>
Revoke a token by jti.
rotate(jti: string,successor: RefreshTokenRecord): Promise<IRefreshTokenRotation>
Atomically consume a live refresh token and persist its successor.
Remote implementations must make the conditional live-token check, parent revocation, successor write, and family-revoked-marker check one atomic operation. This prevents two concurrent refresh requests from minting independent descendants and prevents a rotation after family revocation.
revokeFamily(jti: string): Promise<readonly RefreshTokenRecord[]>
Revoke every refresh token in the requested token's family.
Returns the affected records so the caller can also revoke their paired
access credentials through its separately configured store. Remote
implementations must serialize this operation with rotate() for the
same family: durably mark the family revoked and revoke current members in
one operation, while rotate() atomically rejects a marked family. A
rotation ordered before this operation must have its successor included;
one ordered after it must not persist a successor.