`blursec.sessions`

Session-token verification. One method: verify — the request-aware companion to blursec.credentials.checkToken(token). It pulls a session token straight off an incoming request (auto-detecting JWT vs opaque), runs the same k-anonymity leak check, and returns an enriched result.

Breaking change (1.0.0). The old sessions.kill(userId) and sessions.flag(userId, …) methods were removed. The SDK no longer mutates your session store — that’s your application’s job. sessions is now a read-only risk signal. Revoke compromised sessions in your own store based on the compromised flag.

`verify(input, options?)`

const result = await blursec.sessions.verify(req);

if (result.compromised) {
  await yourSessionStore.revokeAllFor(req.userId);
  return res.status(401).end();
}

verify is also exposed as the client shortcut blursec.verifySession(req).

`input`

Either a raw token string, or any request-like object the SDK can read a token from. It looks, in order, at:

The Authorization: Bearer <token> header
Cookies named by options.cookieName (default: "session")
A custom header named by options.header

// Raw token
await blursec.sessions.verify(rawToken);

// Express / Fetch-style request
await blursec.sessions.verify(req);

// Custom cookie / header names
await blursec.sessions.verify(req, {
  cookieName: ["sid", "__Host-session"],
  header: "x-session-token",
});

`VerifySessionOptions`

Extends CheckOptions (so you get context, failOpen, timeoutMs, signal, severityActions, dryRun) and adds:

interface VerifySessionOptions extends CheckOptions {
  cookieName?: string | readonly string[];  // default: "session"
  header?: string;                          // extra header to inspect
}

`SessionVerificationResult`

Extends CredentialRiskResult with two extra fields:

interface SessionVerificationResult extends CredentialRiskResult {
  tokenType: "jwt" | "opaque";   // how the SDK classified the token
  compromised: boolean;          // convenience: leaked && severity is high/critical
}

compromised is the field most callers branch on — it folds leaked plus a severity threshold into a single boolean so you don’t re-implement the policy.

Fail-open

verify follows the same fail-open contract as credentials.*: transient API/network/timeout/circuit-breaker failures return a safe default (compromised: false, failedOpen: true) instead of throwing. Caller bugs (4xx, validation errors) still throw. Set failOpen: false to opt out per call.

Getting started

Resources

Sessions

`blursec.sessions`

`verify(input, options?)`

`input`

`VerifySessionOptions`

`SessionVerificationResult`

Fail-open

​blursec.sessions

​verify(input, options?)

​input

​VerifySessionOptions

​SessionVerificationResult

​Fail-open

`blursec.sessions`

`verify(input, options?)`

`input`

`VerifySessionOptions`

`SessionVerificationResult`

Fail-open