Email confirmation

Some providers never share an email address (Reddit, TikTok), share one without saying whether it is verified (Kick), or share one that is not always trustworthy (Microsoft, X without email access). VitNode still signs these people in. A returning member is recognized by their provider account, and a new visitor confirms an address of their own by opening an emailed link before any account exists, the same way password sign-ups confirm their email.

When VitNode trusts a provider emailCopy Anchor Link

Signing in at the provider proves the visitor controls that provider account, not that they own the email it reports. So VitNode trusts an address only on the adapter's word, through the emailVerified field that fetchUser returns:

• With emailVerified: true, the adapter asserts the provider verified the address, and VitNode trusts it.
• With emailVerified: false, the address is not trusted, and a new identity confirms an email first.
• With emailVerified omitted, VitNode treats it like true, so adapters written before the field existed keep working. A custom adapter that cannot tell must return false instead.
• With email: null or no email, there is nothing to trust, and a new identity confirms an email first.

Each built-in adapter sets emailVerified from the provider's own flag, such as email_verified, Microsoft's xms_edov or X's confirmed_email; the provider table lists them.

A trusted email can create an account, match an existing account (which then needs its password before linking) and confirm an unconfirmed account. An untrusted email does none of these. It only pre-fills the confirmation form.

What the visitor seesCopy Anchor Link

Why the link only works in the same browserCopy Anchor Link

Without that rule, someone could sign in with their own Reddit account, type your address, and wait for you to click the link out of curiosity. That would create an account under your email that their Reddit account can sign in to.

So the pending sign-in is tied to the browser that started it through an HttpOnly cookie, and the link only finishes it there. Opened anywhere else, such as another browser or a phone, the page says Open the link where you signed in and signs nobody in.

Security rulesCopy Anchor Link

• The pending sign-in lives on the server, in core_sso_pending. The browser holds only a random token in an HttpOnly cookie, and the database stores only hashes of that token and of the link's. Provider tokens are never stored.
• A link works for 30 minutes and once. Sending a new link replaces the old one. The visitor can ask for one every 30 seconds, up to five times.
• VitNode never makes up an address from a username, never treats a successful OAuth sign-in as proof of the email, and never links accounts by an untrusted email.

RequirementsCopy Anchor Link

Confirmation needs an email adapter. Without one, VitNode cannot send the link. A new visitor from such a provider sees We need a verified email, and the callback answers 422 { "error": "email_unavailable" }. Returning members are not affected.

Check the flowCopy Anchor Link

1. Configure an email adapter and a provider that never shares a trusted email, such as Reddit, as the SSO setup shows.
2. In a private window, sign in with a provider account that has never been linked. Confirm your email appears.
3. Enter an address you can read and open the link in the same window. You are signed in as a new member.
4. Sign out and sign in with the same provider account again. You go straight in, with no email step.

APICopy Anchor Link

The email uses the core.auth.sso_confirm_email.email translations, so it follows the visitor's language.

RelatedCopy Anchor Link