What is JWT Authentication? A Signed Claim Set, and Where the Row Scope Sits

Most explanations of JWT authentication stop at the anatomy: header, payload, signature, and how to verify one. That part is well covered and this page does not repeat it.

The part that decides whether an embedded dashboard is safe sits one step later. In a customer-facing dashboard the token is not only a description of who the viewer is. It travels alongside the instruction that decides which rows the viewer gets, and whether one signature covers both is a question worth answering before launch.

A Signature Proves Where a Claim Set Came From, Not That the Claims Are True

A JSON Web Token is a set of claims plus a signature over them. Verifying the signature establishes that the token was issued by a party holding the key and has not been altered since. It establishes nothing about whether the claims still describe the person presenting the token.

That gap is why RFC 7519 gives timing its own claims. The specification defines that "the 'exp' (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing", and that "the 'nbf' (not before) claim identifies the time before which the JWT MUST NOT be accepted for processing". (RFC 7519, read 24 August 2026.)

The other three registered claims worth naming here are equally plain. "The 'iss' (issuer) claim identifies the principal that issued the JWT", "the 'sub' (subject) claim identifies the principal that is the subject of the JWT", and "the 'aud' (audience) claim identifies the recipients that the JWT is intended for".

Read that list again and notice what is missing. None of the five says anything about which data the holder may see.

Scope Is Not a Registered Claim, So It Lives Where the Specification Warns You to Be Careful

Because scope has no registered claim, the fields that carry it are either public claim names or private ones. RFC 7519 describes public names as collision-resistant and registered, and it addresses the private case directly: "A producer and consumer of a JWT MAY agree to use Claim Names that are Private Names: names that are not Registered Claim Names or Public Claim Names. Unlike Public Claim Names, Private Claim Names are subject to collision and should be used with caution."

That sentence is usually read as naming advice. In an embedded dashboard it is more than that, because the colliding name is the one that decides a tenant boundary.

The figure separates the two halves on purpose. A token can be perfectly formed and a row policy perfectly written while neither one is reading the other.

In Our Own Documented Example the Signature Covers the Dashboard, and the Scope Is Documented Separately

Concrete beats abstract here, so this section uses our own documentation rather than a generalisation about vendors.

Sumboard's back-end setup page instructs you to "create an endpoint on your backend that uses the company secret key and dashboard shared token to generate and return the token", and shows the signing step as sign({ st }, companySecretKey) where st is the dashboard shared token. (Sumboard docs, Back-end setup, read 24 August 2026.)

So the payload in that example names the dashboard and nothing else. The viewer's scope arrives through the parameters documented on a separate page, where the static token page names user, value, label and params, and those pages do not state that the parameters travel inside the signed payload. (Sumboard docs, Embed with static token parameter, read 24 August 2026.)

That distinction is the one to settle first in any stack, ours included. A field that decides scope but rides outside the signature is protected by whatever else is protecting the request.

The Documentation Puts Scope on the Backend, and the Reason Holds Beyond the Guidance

The same page states the guidance with its own qualifiers: "Token type filters are typically initialized on the backend as parameters and should not be transmitted from the frontend."

The reasoning underneath it is ours rather than the documentation's, and it is worth saying out loud. A value the viewer can edit is not evidence about that viewer, so a tenant identifier that arrives from the browser proves only that the browser sent it.

The documentation frames the goal the same way, describing the method as the one used "when you need to offer the same dashboard to multiple users within your application while ensuring each user accesses only their personalized data". One dashboard, many viewers, and the parameters are what separate them.

When the Claim Set and the Row Policy Disagree, Something Wins, and It Should Not Be Whichever Runs First

This is the failure that generic JWT material has no reason to discuss, because it only appears when a token is a scope rather than an identity.

Take a stack where the token says the viewer belongs to tenant B while a row policy at the data layer reads a pooled service connection and sees no viewer at all. Both components are working as written, and the query returns whatever the weaker of the two allows. This scenario is our engineering reading rather than a documented behaviour of any particular database.

The design question is therefore not "do we use JWTs" but which layer is authoritative and how the other one learns about it. A row-level security policy scoped to viewer context cannot read a viewer out of a connection identity, so the token's claims have to reach the policy as context the policy evaluates.

An Expiry You Cannot Name Is an Expiry You Cannot Test

RFC 7519 gives you exp and nbf, and the whole value of those claims is that somebody picks the numbers.

Our own back-end setup page does not state a validity window for the generated token. That is a documentation gap on our side rather than evidence about the underlying behaviour, and it is the kind of thing worth asking any vendor to state in writing before launch.

The reason it matters in a dashboard specifically is the session shape. A token that expires mid-session produces a panel that fails after a viewer has already started reading, which is a different user experience problem from a login page that asks you to sign in again.

Three Questions That Separate a Working Token Design From a Signed One

Ask which layer is authoritative for scope. A good answer names one layer and explains how the other receives the same context, rather than describing both as secure.

Ask what a missing claim does. The safe behaviour is to fail closed and return nothing, because a scope claim that silently defaults to everything is the failure that looks like success.

Ask where the claim is set. If any part of the scope can be supplied by the browser, the answer to "which rows can this viewer reach" is decided by whoever holds the browser.

Related Authentication and Isolation Concepts

• Row-level security: what a row policy decides, and what it does not.
• Embedded analytics security: the paths the data takes, including the ones a scheduled job opens.
• GDPR and embedded analytics: what happens to the derived copies of the rows a token once scoped.
• Embedded analytics guide: the routes to shipping it, and what each one leaves you owning.