Skip to main content

JWT Tokens

DocuTrust uses JSON Web Tokens (JWT) to authenticate embedded signing forms and template builders. Tokens are generated server-side, scoped to a specific resource (submitter or template), and passed to the frontend embed components.

Overview

Token types

DocuTrust issues two types of embed tokens, each scoped by the aud (audience) claim.

Form tokens

Form tokens authenticate a signing session for a specific submitter. The sub claim contains the submitter ID, and the sid claim contains the submission ID. Full JWT claims:
Claim reference:

Builder tokens

Builder tokens authenticate access to the template editor for a specific template. The sub claim contains the template ID. Full JWT claims:
Claim reference: When opts.fields is populated, it contains field definition objects:

Expiration defaults

Tokens are validated on every request. An expired token returns a 401 Unauthorized response with:

Generating tokens via the API

Use POST /api/embed/token to generate embed tokens. Authenticate with your API token in the X-Auth-Token header.

Generate a form token

Response:

Generate a builder token

Response:

Server-side token generation

For tighter control or when you want to generate tokens without calling the API, you can sign JWTs directly using your account’s JWT secret.

Ruby

Node.js

Python

Security best practices

Never expose your JWT secret to the browser. Tokens must always be generated on your backend and passed to the frontend. The JWT secret should only exist in environment variables on your server.
The default 4-hour expiration is suitable for most use cases. For high-security environments, generate tokens with shorter lifetimes (15-60 minutes) and refresh them as needed.
Each token should be scoped to exactly one submitter (form) or one template (builder). Never create tokens that grant access to multiple resources. The sub claim enforces this scoping.
If your JWT secret is compromised, rotate it immediately in your DocuTrust account settings. All existing tokens signed with the old secret will be invalidated. DocuTrust supports a previous key for graceful rotation — tokens signed with the previous key remain valid during the rotation window.
When verifying tokens on your backend (e.g., in webhook handlers), always validate the aud claim matches the expected audience. A form token should never be accepted where a builder token is expected, and vice versa.
Avoid passing JWT tokens as URL query parameters. URLs are logged in server access logs, browser history, and proxy logs. Instead, pass tokens via data-token attributes or JavaScript configuration objects.

Token flow diagram

The typical token flow for embedding:
1

Backend generates token

Your server calls POST /api/embed/token (or signs a JWT directly) with the submitter/template ID and desired options.
2

Token sent to frontend

Your backend returns the token to the browser, either as part of an HTML page render or via an AJAX response.
3

Frontend passes token to embed

The token is set as a data-token attribute on the web component, or passed to DocuTrust.mount() / DocuTrust.mountBuilder().
4

Embed validates token

The DocuTrust iframe receives the token, validates the signature and expiration, and loads the appropriate resource (form or builder).
5

Token expires

After the configured expiration time, the token is no longer valid. If the user’s session is still active, your backend should generate a fresh token.

Troubleshooting