ThunderIDNodeClient

ThunderIDNodeClient is an abstract base class that extends ThunderIDJavaScriptClient with Node.js-specific configuration. Use this class as the foundation when building a new framework-specific authentication client for a Node.js runtime. Examples include adapters for other Node.js server frameworks.

Overview

ThunderIDNodeClient inherits all methods from ThunderIDJavaScriptClient and applies the ThunderIDNodeConfig type by default. Because the class is abstract, you cannot instantiate it directly. Instead, extend it and implement any framework-specific initialization or middleware logic in the subclass.

Usage

src/MyFrameworkClient.ts

ts

import { ThunderIDNodeClient, ThunderIDNodeConfig } from '@thunderid/node'

interface MyFrameworkConfig extends ThunderIDNodeConfig {
  customOption?: string
}

class MyFrameworkClient extends ThunderIDNodeClient<MyFrameworkConfig> {
  // Add framework-specific methods or override inherited ones here
}

export default MyFrameworkClient

Type Parameter

Parameter	Default	Description
T	ThunderIDNodeConfig	Configuration type. Extend ThunderIDNodeConfig to add framework-specific configuration fields.

Node-Specific Methods

Not inherited from ThunderIDJavaScriptClient: these methods exist only on ThunderIDNodeClient and its subclasses (ThunderIDExpressClient, ThunderIDNextClient).

updateUserCredentials(payload, userId?)

Updates one or more of a signed-in user's credentials, for example password, or any other attribute the user type schema declares credential: true. Calls POST /users/me/update-credentials with the session's access token attached.

ts

updateUserCredentials(payload: Record<string, string>, userId?: string): Promise<void>

AuthService.mjs

ts

await client.updateUserCredentials({ password: 'n3wP@ssword!' }, userId)

Parameters:

Parameter	Type	Description
payload	Record<string, string>	New values keyed by credential attribute name (for example password)
userId	string (optional)	Session identifier to read the access token from

Returns: Promise<void> - The endpoint responds with 204 No Content on success. Throws ThunderIDAPIError on failure.

note

This method collects only the new value, it does not verify the account's current value first. The self-service credential write path does not check the current value today.

handleBackchannelLogout(logoutToken)

Handles an OpenID Connect back-channel logout. Validates the logout token ThunderID posted, then ends every local session it names. See Back-Channel Logout for what the token contains and how ThunderID delivers it.

ts

handleBackchannelLogout(logoutToken: string): Promise<BackchannelLogoutResult>

routes/backchannel-logout.mjs

ts

import {InvalidLogoutTokenError} from '@thunderid/node'

// Behind a POST route that parses an application/x-www-form-urlencoded body
res.set('Cache-Control', 'no-store')
try {
  await client.handleBackchannelLogout(req.body.logout_token)
  res.status(200).end()
} catch (err) {
  // 400 tells ThunderID not to retry. A 5xx makes it retry.
  res.status(err instanceof InvalidLogoutTokenError ? 400 : 500).end()
}

Parameters:

Parameter	Type	Description
logoutToken	string	The raw logout_token form parameter

Returns: Promise<BackchannelLogoutResult>

Property	Type	Description
sid	string (optional)	The session the token named
sub	string (optional)	The subject the token named
issuedAt	number	The token's iat, in seconds
sessionsEnded	number	How many local sessions were ended. 0 when the token named no session held here, which is still a success

Throws: InvalidLogoutTokenError when the token is not valid or its jti was already handled. Answer 400 for it. Any other error means the logout could not be recorded; answer a 5xx, so ThunderID retries.

Behavior:

• A token with a sid ends the sessions that joined that ThunderID session. A token with only a sub ends that subject's sessions that began before the token was issued, within the configured ID token clock tolerance.
• The client records the sid and sub of the ID token against each session when signIn() completes, so a logout token can find it. The records live in the same storage adapter as the sessions and are removed when a session is cleared or its token revoked.
• Ending a session is local. The method does not call the revocation or end session endpoint.
• An access token the application already handed to a browser or to another service stays valid until it expires.
• The jti replay check is kept in the process. Sessions and their records live in memory by default; a deployment with more than one instance needs a shared storage adapter.
• An encrypted logout token is not supported.

Related

• ThunderIDNodeConfig: Configuration type for this client