You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
LockContext via OidcFederationStrategy: lock encryption by JWT claim, no manual JWT handling #529
Today, identity-aware encryption requires the developer to manage the OIDC JWT by hand:
constlc=newLockContext()constidentified=awaitlc.identify(userJwt)// caller fetches + passes the JWTawaitclient.encrypt(...).withLockContext(identified.data)
LockContext.identify(jwt) hand-rolls the OIDC→CTS federation (a raw fetch() to /api/authorize with { workspaceId, oidcToken }) and the caller is responsible for sourcing a current, unexpired JWT on every call. This is the same federation that @cipherstash/auth's OidcFederationStrategy now performs — with token caching/refresh and workspace assertion built in.
Desired end state
When an OidcFederationStrategy is configured on the client, encryption/decryption calls can be "locked" simply by specifying a JWT claim (e.g. the identity claim), with no manual identify(jwt) step:
// strategy created once with OidcFederationStrategy (getJwt provided)awaitclient.encrypt(...).withLockContext({claim: 'sub'})// shape TBD
The strategy owns fetching/refreshing/federating the JWT; the SDK derives the lock context from the configured claim. Devs no longer thread raw JWTs through every operation.
Dependency (now available)
OidcFederationStrategy shipped in @cipherstash/auth0.40.0 in both the Node entry and @cipherstash/auth/wasm-inline (create(workspaceCrn, getJwt, baseUrl?) / createWithStore(...)). The CRN/region parity bump that brings auth 0.40.0 into stack lands in #528 (CIP-3245).
Notes / open questions
API shape for "lock by claim" on .withLockContext() — accept a claim selector vs. a small options object.
Migration/back-compat for the existing new LockContext().identify(jwt) flow (keep as a lower-level escape hatch?).
@cipherstash/protect has a parallel LockContext (src/identify/index.ts) that hand-rolls the same federation — decide whether it consolidates onto the strategy too.
Separate from #523/#528 (that work is the AccessKeyStrategy CRN parity bump; this is a new identity model built on OidcFederationStrategy).
Already implemented in #497, which replaces the LockContext.identify(jwt) ceremony with strategy-based .withLockContext({ identityClaim }) via OidcFederationStrategy (deprecating identify()). Not separate work after all — closing as a duplicate of #497's scope.
Follow-up: #1045. OidcFederationStrategy caches one CTS token per instance, so a single client serving several users reuses the first user's token, and that includes the lock-context binding.
Activity
coderdan commentedon Jun 29, 2026
Already implemented in #497, which replaces the
LockContext.identify(jwt)ceremony with strategy-based.withLockContext({ identityClaim })viaOidcFederationStrategy(deprecatingidentify()). Not separate work after all — closing as a duplicate of #497's scope.coderdan commentedon Oct 4, 2026
Follow-up: #1045.
OidcFederationStrategycaches one CTS token per instance, so a single client serving several users reuses the first user's token, and that includes the lock-context binding.