n8n JWT invalid signature error – fix for N8N_JWT_AUTH_HEADER and token misconfig

 

Who this is for: Developers and DevOps engineers configuring n8n webhooks that rely on JWT‑based security. We cover this in detail in the n8n Security & Hardening Guide.

Quick diagnosis – Your n8n instance rejects valid JWTs (401 Unauthorized) or accepts expired/altered tokens. The root cause is usually a mismatched secret, wrong algorithm, incorrect token extraction, or disabled verification flags.

Fix in one line – Make sure the secret (JWT_SECRET) and algorithm (jwtAlgorithm) exactly match the values used to sign the token, then enable Signature and Expiration verification in the JWT Verify node.

1. How n8n Handles JWT Tokens ?

Component	Where it lives	Default	Purpose
JWT_SECRET	process.env.JWT_SECRET (env var)	None – must be set	Secret key the JWT Verify node uses to decode and validate the token.
JWT_ALGORITHM	Node setting jwtAlgorithm	HS256	Cryptographic algorithm (HS256, RS256, …) that must match the token’s alg header.
jwtVerifyOptions	Node config (verifySignature, verifyExpiration, verifyAudience)	All true	Toggles individual verification steps.

EEFA note – Never store the secret in plain text inside a Dockerfile or public repository. Use a secret manager (AWS Secrets Manager, HashiCorp Vault, etc.) and expose it only as an environment variable at runtime.

2. The 5 Most Common JWT Misconfigurations in n8n

If you encounter any default credentials vulnerability resolve them before continuing with the setup.

#	Misconfiguration	Why it breaks	Corrective action
1	Secret mismatch – different secret in dev vs. prod	Signature verification fails → 401	Store the same secret across all environments or inject it via a secret manager.
2	Algorithm mismatch – signing with RS256 but node defaults to HS256	Signature verification fails because the algorithm differs.	Set jwtAlgorithm to the exact algorithm used (e.g., RS256).
3	Missing token extraction – feeding the whole Authorization header	Node expects only the raw token; the Bearer prefix causes a decode error.	Strip the prefix before passing the token.
4	Disabled verification flags – turning off verifyExpiration or verifySignature	Expired or tampered tokens are accepted – a severe security hole.	Keep all verification flags enabled in production; only disable in isolated test environments.
5	Clock skew not accounted for – token issued just before server time sync	Small time differences cause “jwt expired”.	Configure clockTolerance (e.g., 5 seconds) in the node’s advanced options.

3. Step‑by‑Step: Correctly Configuring JWT Verification in n8n

3.1 Generate a strong secret

# Generate a 256‑bit base64 secret
openssl rand -base64 32

Store the output in your secret manager and expose it as JWT_SECRET at runtime. If you encounter any environment variable secrets leakage resolve them before continuing with the setup.

3.2 Add the JWT Verify node

Field	Value
Token	{{$json["headers"]["authorization"].replace("Bearer ", "")}}
Secret	{{ $env.JWT_SECRET }}
Algorithm	*Select the algorithm you used to sign (e.g., RS256)*
Verification flags	Enable Signature, Expiration, Audience (if applicable)

3.3 Optional verification options (clock tolerance)

{
  "clockTolerance": 5,
  "ignoreNotBefore": false
}

Paste the JSON into the *Advanced* tab of the node.

3.4 Test with a known‑good token

curl -X POST https://your-n8n-instance/webhook/xyz \
  -H "Authorization: Bearer <your_jwt>"

A 200 response and the decoded payload in the node’s output confirm correct setup.

3.5 Deploy with environment‑specific secrets

Docker Compose

services:
  n8n:
    image: n8nio/n8n
    environment:
      - JWT_SECRET=${JWT_SECRET}

Kubernetes (excerpt)

apiVersion: v1
kind: Secret
metadata:
  name: n8n-jwt-secret
type: Opaque
data:
  JWT_SECRET: <base64‑encoded-secret>
---
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
        - name: n8n
          envFrom:
            - secretRef:
                name: n8n-jwt-secret

4. Debugging JWT Failures in n8n

If you encounter any insecure webhook exposure resolve them before continuing with the setup.

Symptom	Likely cause	Debug steps
401 – Invalid signature	Secret or algorithm mismatch	1️⃣ Add a Set node to output {{ $env.JWT_SECRET }}. 2️⃣ Compare with the secret used by the signing script.
401 – Token expired	Clock skew or wrong exp claim	Use a Function node to log Date.now()/1000 vs. {{$json["payload"]["exp"]}}. Adjust clockTolerance.
401 – Missing token	Header not passed or stripped incorrectly	Add a Debug node after the webhook to output {{$json["headers"]}}.
200 OK but payload empty	Payload not mapped downstream	Reference the node’s output explicitly: {{$node["JWT Verify"].json["payload"]}}.

Quick tip – Enable Full Execution Logging in Settings → Execution to capture the exact token string and verification errors in the n8n logs.

5. Production‑Ready Best Practices & EEFA Checklist

• [ ] Store JWT_SECRET in a dedicated secret manager; never commit to Git.
• [ ] Prefer asymmetric keys (RS256/ES256) for inter‑service tokens; keep private keys offline.
• [ ] Rotate secrets regularly (e.g., every 90 days) and implement a kid‑based rotation strategy.
• [ ] Enforce HTTPS on all n8n endpoints – JWTs over plain HTTP can be intercepted.
• [ ] Enable verifyAudience and verifyIssuer when applicable to limit token reuse.
• [ ] Monitor logs for repeated JWT failures – could indicate an attack vector.
• [ ] Keep token lifetimes short (e.g., 15 min for UI sessions) and renew them as needed.

EEFA note – When using RSA keys, provide the public key via JWT_PUBLIC_KEY env var. If the key cannot be loaded, n8n falls back to HS256 verification, which may silently accept malformed tokens.

Conclusion

Aligning the secret, algorithm, and verification flags between your token issuer and n8n’s JWT Verify node eliminates the most common authentication errors. By extracting the raw token correctly, enabling full verification, and managing secrets securely, you ensure that only properly signed and unexpired JWTs reach your workflows. Apply the production checklist to harden your deployment, rotate keys regularly, and monitor for anomalies—keeping your n8n instance both functional and secure in real‑world production.