Signing your own users in
Your server signs a short JWT, we verify it and admit the holder — with a harness that tells you which part is wrong before you ship.
If people are already logged in to your product, they should not log in again to leave you feedback. Your server signs a token that says who they are, links them to your board with it, and they arrive identified.
This is single sign-on in the sense of your users, not a SAML directory. There is nothing to configure with an identity provider and no metadata to exchange: a shared secret and a signed JWT is all of it.
Brand plan. Open Install in your workspace to get your secret.
The token
Sign a JWT with HS256, using the secret from the Install screen.
{
"id": "8f2c1b",
"email": "dana@example.com",
"name": "Dana Hart",
"avatarUrl": "https://example.com/avatars/dana.png",
"exp": 1760000000
}
| Claim | Required | What it is |
|---|---|---|
id | yes | Your own id for this person, unique within your system. sub is accepted instead. |
email | no | Used to tell them when something they voted for ships. |
name | no | What appears on their posts and comments. |
avatarUrl | no | Their picture. |
exp | recommended | Expiry. Sign a short-lived token per page load. |
id is the identity. Everything else can change — somebody renames themselves,
changes their address — and they stay the same person on your board.
Never put the secret in your front end. The token is signed on your server. Anything in a browser bundle is a secret your users have.
The link
Send them to your board with the token on the query string:
https://yourworkspace.nolby.co/api/sso?token=<jwt>&next=/b/feedback
We verify the token, set a session cookie and send them to next. From then on
every request on that host carries it, for twelve hours.
next has to be a path on your board — a full URL pointing somewhere else is
refused, so this cannot be used as an open redirect in your product.
If verification fails they land on the board anyway, signed out, and the sign-in sheet says the integration is broken rather than offering them a code they do not have.
Anything they did anonymously in that browser before signing in — a vote, a post — becomes theirs at the moment they arrive.
Check it before you ship
The Install screen has a field you can paste a token into. It verifies it exactly as the real door does and names what is wrong:
| It says | What to change |
|---|---|
| No secret yet. | Generate one above first — there is nothing to verify against. |
| That is not a JWT. | Three base64url segments separated by dots. Usually the whole signing response got pasted instead of the token out of it. |
| Signed with the wrong algorithm. | HS256 only. Pass the shared secret rather than a key pair. |
| Signature does not match. | Well-formed, signed with a different secret — most often the staging key in production. |
| Expired. | Your secret is right and the token is old. Mint it per page load rather than caching it. |
| No user id in the token. | Your secret is right. Add an id claim, or sub. |
Each of those names the thing to go and change rather than reporting a status, because invalid token is the message that turns a twenty-minute integration into an afternoon.
Paste a real token from your own server rather than one made by hand — the mistakes worth catching are in how your code signs it.
Rotating the secret
Minting a new secret on the Install screen invalidates the old one immediately. Tokens already signed with it stop verifying, so deploy the new secret and rotate in the same change.