Identity
Signing in your users
Record every vote, comment and suggestion against the person who left it, using the sign in your product already has. Your users never see a VoteFirst account.
The shape of it: your server signs a short lived token saying who this person is, your page hands that token to the script, and the board takes them at their word because only your server could have signed it.
The three steps, with the code for your own server, are in the SSO quickstart. This page is what sits underneath them: what a token may say, what happens when one is refused, and what the plan has to be.
The claims
{
"sub": "user_123", // required, your own id for this person
"exp": 1713686400, // required, when the token stops working
"email": "user@example.com", // optional, kept on the voter's profile
"name": "Jane Doe" // optional, the name on their comments
}
| Claim | Required | What it carries |
|---|---|---|
sub | Yes | Your own id for this person, as a string or a number, so an integer primary key works as it stands |
exp | Yes | When the token stops working. A token without one is refused |
email | No | Kept on the voter's profile |
name | No | The name on their comments. Without it a visitor still votes as themselves and comments under a generated handle |
Signed with HS256, HS384 or HS512. A numeric sub is refused if it is zero, fractional, or larger than a JSON number holds exactly, because past that two of your ids would round together and two people would share one voter. Ids that long belong in a string, where they are taken as written. Otherwise 42 and "42" are the same person, so a signing library that quotes integers and one that does not are both fine.
Keep the lifetime short. The token is the credential itself, checked again on every request rather than exchanged for a session, and nothing withdraws a single token before it expires.
The voter it makes
A signed in visitor becomes the voter sso_<project>_<sub>, so the same person is a different voter on each of your projects and no project can read another's. Nothing you send is used to link them.
name and email are written onto that voter's profile from every token that arrives, so correcting somebody's name in your own product corrects it here on their next visit. Their comments keep the name they were left under.
A request carrying both a signed in token and an anonymous one is a visitor who has just signed in, and the signed in token wins: it is an authenticated claim, where the anonymous token is a value the browser happens to be holding.
When a token is refused
A refused token drops the visitor back to voting anonymously rather than locking them out, and the reason reaches the error event. That reason is the same sentence for every kind of refusal, deliberately, because the page it lands in is a public one.
To find out which kind it was, paste what your server produced into Test a token in the dashboard. The check records nothing, spends none of your project's budget, and names the reason.
Plan
SSO needs the project owner on the PRO plan at the moment of each request. If the plan lapses the board carries on working and every signed in visitor quietly becomes anonymous, which is worth knowing before you go looking for the bug in your signing code.