> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blursec.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Sessions

# `blursec.sessions`

Session-token verification. One method: `verify` — the request-aware companion to
[`blursec.credentials.checkToken(token)`](/docs/resources/credentials). 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?)`

```ts theme={null}
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:

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

```ts theme={null}
// 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`](/docs/resources/credentials#checkoptions) (so you get
`context`, `failOpen`, `timeoutMs`, `signal`, `severityActions`, `dryRun`) and
adds:

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

### `SessionVerificationResult`

Extends [`CredentialRiskResult`](/docs/resources/credentials#credentialriskresult)
with two extra fields:

```ts theme={null}
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](/docs/errors) 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.