Skip to main content

Signed Identities: Secure your users with JWT-signed identities

A
Written by Alex

What you'll learn

  • Why signed identities matter for security

  • How to generate an RSA key pair

  • How to upload your public key to Fullview

  • How to create a signed identity endpoint on your backend

  • How to keep identities fresh on the frontend

  • How to verify everything works

What are signed identities?

When you install Fullview, your application tells Fullview who each user is — their ID, name, email, and any custom data — by setting window.$fvIdentity. By default, this object can be set by any code running on the page.

That means a malicious actor could open browser DevTools and set window.$fvIdentity to someone else's user ID. From Fullview's perspective, they would appear to be that user. They could then trigger cobrowse sessions, view session replays of that user, or take other actions as that user.

Signed identities solve this by requiring identities to be cryptographically signed by your backend using a private key that only you possess. Fullview verifies each identity using your public key. If the signature doesn't match, the identity is rejected.

Once signed identities are enabled:

  • Only identities signed by your backend will be accepted

  • Anyone trying to impersonate a user in browser DevTools will be blocked

  • Your users' data and sessions are protected by cryptographic guarantees

How it works (at a glance)

The cryptography uses RS256 (asymmetric RSA signing). You keep the private key secret on your backend. Fullview only ever sees the public key, which by design cannot be used to forge identities.

Step 1: Generate an RSA key pair

You need a 2048-bit (or stronger) RSA key pair in PEM format. You can use whatever tool you prefer — here are a few examples:

This produces two files:

  • fullview_private.pem — Your private key. Keep this secret. Never share it, never expose it in frontend code, never commit it to source control. We recommend storing it as an environment variable (e.g., FULLVIEW_PRIVATE_KEY) or in a secrets manager.

  • fullview_public.pem — Your public key. This is safe to share with Fullview and only used for signature verification.

Step 2: Upload your public key to Fullview

  1. In the Fullview dashboard, navigate to Settings → Security.

  2. Under Signed identities → Upload the public key, click Add public key.

  3. Paste the contents of your fullview_public.pem file and save.

You'll see the key appear with the date it was added.

About key rotation: You can add additional public keys at any time. If at least one of your uploaded keys can verify a given signature, the identity will pass. This means you can rotate keys safely by:

  1. Generating a new key pair

  2. Uploading the new public key (now both old and new are accepted)

  3. Switching your backend to sign with the new private key

  4. Once all old tokens have expired, removing the old public key

Step 3: Create a signed identity endpoint on your backend

You need an endpoint on your backend that:

  1. Identifies the currently authenticated user (using whatever auth system you already have)

  2. Generates a signed JWT containing that user's identity

  3. Returns the JWT to your frontend

Below is an example in Node.js. Examples for Go, .NET, Java, and Python are available directly in your Fullview dashboard under Settings → Security → Step 3 — refer there for the latest versions.

Node.js

What the JWT payload contains

When generating the JWT, populate these claims:

Claim

Required

Description

id

Yes

Your internal user identifier — must be unique and stable per user

name

Yes

Display name shown to your support agents in Fullview

email

No

User's email — improves search and identification

roles

No

Array of role strings — useful for segmentation (e.g., ["admin"])

env

No

User's environment context — useful for segmentation (e.g., "production")

disableReplaysForUser

No

If true, Fullview will not record this user's session replays

custom

No

Object containing any custom fields you want to track (plan tier, account type, etc.)

exp

Auto

Expiration time. Set via expiresIn in most JWT libraries. We recommend 1 hour.

iat

Auto

Issued-at timestamp. Set automatically by most JWT libraries.

Always sign with RS256. Other algorithms (HS256, etc.) are not supported.

Step 4: Wire up the frontend with $fvIdentityRefresh

Once your backend can produce signed JWTs, your frontend needs to fetch them and hand them to Fullview. The cleanest way is to expose a function on window.$fvIdentityRefresh:

Once this is set up, Fullview will:

  • Call this function automatically when an identity is needed

  • Refresh the identity proactively before it expires (no waiting for failed requests)

  • Cache the identity in memory between refreshes

You can also call it manually to force a refresh — useful right after login or whenever the user's data changes:

If successful, window.$fvIdentity will be a string (the JWT) rather than an object. It will look something like:

This is expected. The JWT is opaque from the frontend's perspective — it's just a signed token. Fullview decodes and verifies it server-side.

Step 5: Enable signed identities

Once you've completed steps 1-4 and tested in a staging environment, you can flip signed identities from Disabled to Enabled in the dashboard.

Important: Once enabled, any unsigned identities will be rejected. If your backend or frontend integration has any issues, your Fullview integration will break. We strongly recommend:

  1. Test the full flow in a staging or development environment first

  2. Verify your backend reliably returns valid JWTs

  3. Verify your frontend correctly sets up window.$fvIdentityRefresh

  4. Only then enable signed identities in production

Troubleshooting

My users aren't appearing in Fullview after enabling signed identities.

Most likely cause: the JWT is failing verification. Check:

  • Is your FULLVIEW_PRIVATE_KEY env var the exact matching pair of the public key you uploaded?

  • Is your JWT being signed with RS256 (not HS256 or another algorithm)?

  • Is the JWT non-expired (exp claim is in the future)?

  • Open browser DevTools — is window.$fvIdentity a long string starting with eyJ?

I'm seeing identity-related errors only intermittently.

Often a token-expiration issue. Make sure $fvIdentityRefresh is properly set up so tokens refresh before they expire. If you're using a very short expiration time (e.g., 5 minutes), consider lengthening it — 1 hour is a good default.

I rotated my private key and now everything is broken.

Add the new public key in the dashboard before switching your backend over to sign with the new private key. Keep both public keys uploaded during the transition until any tokens signed with the old key have expired.

Can I roll back if something goes wrong?

Yes. Disable signed identities from Settings → Security and your integration will revert to the legacy unsigned identity flow. Your data is not affected.

Need help?

Contact our team in your shared Slack channel, or reach out at support@fullview.io.

Did this answer your question?