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 theaud (audience) claim.
Form tokens
Form tokens authenticate a signing session for a specific submitter. Thesub claim contains the submitter ID, and the sid claim contains the submission ID.
Full JWT claims:
Builder tokens
Builder tokens authenticate access to the template editor for a specific template. Thesub claim contains the template ID.
Full JWT claims:
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
UsePOST /api/embed/token to generate embed tokens. Authenticate with your API token in the X-Auth-Token header.
Generate a form token
Generate a builder token
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
Generate tokens server-side only
Generate tokens server-side only
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.
Use short expiration times
Use short expiration times
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.
Scope tokens to specific resources
Scope tokens to specific resources
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.Rotate your JWT secret
Rotate your JWT secret
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.
Validate the audience claim
Validate the audience claim
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.Do not embed tokens in URLs
Do not embed tokens in URLs
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.