Tribe handles login, registration, and session management in a single integration. You can get up and running in minutes with pre-built hosted pages, or wire up your own custom forms when your design calls for it. The choice comes down to how much control you want over what users see.
Hosted Auth Pages
Redirect users to Tribe’s hosted login and registration pages. There’s no UI code to write on your end: call redirectToLogin(), and Tribe handles the rest.
Best for: Getting authentication working quickly, or when a custom design isn’t a priority.
Custom Login UI
Build your own login and registration forms with tribe.login() and tribe.register(). You own the entire UI while Tribe manages sessions and security behind the scenes.
Best for: Apps where authentication needs to match your brand’s look and feel.
Users can sign in through several mechanisms, and each one handles identity differently:
| Method | Privacy | How it works |
|---|---|---|
| Email/password | Email stored | The traditional approach. Users register with an email and password, and Tribe runs breached password checks automatically. |
| Social login | Pseudonymous | OAuth redirect through Google, GitHub, Discord, or Twitter. Tribe stores only a hashed identifier, never the user’s actual email. |
| Wallet login | Pseudonymous | Solana wallet sign-in via Phantom, Backpack, or Solflare. Ownership is verified through a cryptographic signature challenge. |
| Google Sign-In | Pseudonymous | Client-side Google login where the server never sees the real Google identity. All that’s persisted is a hashed ID. |
| Passkey login | Pseudonymous | WebAuthn authentication using biometrics (Face ID, Touch ID) or hardware security keys. Phishing-resistant and passwordless. |
| Magic links | Email stored | Passwordless login over email. The user clicks a link and lands in a signed-in session. |
Every method produces the same session format, so your application code doesn’t need to care which path the user took.
After a user logs in through any method, the SDK stores a session token in localStorage. You can check for an active session on each page load:
const session = await tribe.getSession();if (session) { console.log("Logged in as:", session.user.id); console.log("User token:", session.userToken); // JWT for backend verification} else { console.log("Not logged in");}The userToken is a JWT signed with your site’s TRIBE_KEY. You can verify it on your backend to confirm the user’s identity without making a network call back to Tribe.
For auth methods that don’t involve email (social login, wallet, Google Sign-In, passkeys), Tribe stores only a pseudonymous hash derived from the provider’s user ID and a per-site salt. The user’s real email and identity never touch the database.
pseudonymousId = SHA256(provider + ":" + userId + ":" + siteSalt)In practice, this means user.email will be null for these users, and user.pseudonymousId serves as the stable identifier you should use in your app. Even if the database were breached, real identities would remain protected because the hash can’t be reversed without the original provider ID.
Passkeys fit naturally into this privacy model. Since WebAuthn credentials are bound to the user’s device and domain, they don’t expose any external identity at all. Combined with session verification, passkeys also let you protect accounts against suspicious logins from unrecognized devices, without requiring users to hand over an email address or phone number.