JWT Tokens
SpitShake 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
SpitShake 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
Security best practices
Request tokens from your backend
Request tokens from your backend
POST /api/embed/token needs your API token, so call it from your server and pass only the resulting embed token to the browser. Never put the API token in browser code.Mint a token per session
Mint a token per session
Form and builder tokens last 4 hours. Request a fresh one each time you render the embed instead of storing one.
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.Token types are not interchangeable
Token types are not interchangeable
SpitShake checks the
aud claim: a form token is rejected on the template routes and a builder token on the signing routes. A form token also opens only the submission it was minted for. A builder token reads its template; edits go through PUT /api/templates/{id}.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 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 SpitShake.mount() / SpitShake.mountBuilder().4
Embed validates token
The SpitShake 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.

