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 | authMethod | How it works |
|---|---|---|---|
| Email/password | Pseudonymous | "password" | Users register with an email and password. The email is used transiently to derive a pseudonymous ID but is never stored. Tribe runs breached password checks automatically. |
| Social login | Pseudonymous | "github", "discord", etc. | OAuth redirect through Google, GitHub, Discord, or Twitter. Tribe stores only a hashed identifier, never the user’s actual email. |
| Wallet login | Pseudonymous | "wallet" | Solana wallet sign-in via Phantom, Backpack, or Solflare. Ownership is verified through a cryptographic signature challenge. |
| Google Sign-In | Pseudonymous | "google" | Client-side Google login where the server never sees the real Google identity. All that’s persisted is a hashed ID. |
| Passkey login | Pseudonymous | "passkey" | WebAuthn authentication using biometrics (Face ID, Touch ID) or hardware security keys. Phishing-resistant and passwordless. |
| Magic links | Pseudonymous | "email" | Passwordless login over email. The email is used transiently to send the link and derive a pseudonymous ID, but is never stored. |
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.
All auth methods are fully pseudonymous. For email/password and magic link users, the email is used transiently to compute a pseudonymous ID but is never stored. For social login, wallet, Google Sign-In, and passkey users, the provider’s user ID is hashed the same way. In every case, Tribe stores only a one-way hash derived from the user’s identifier and a per-site salt:
pseudonymousId = SHA256(provider + ":" + userId + ":" + siteSalt)In practice, this means user.email will always be null. 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 identifier.
Features like password reset, email verification, and magic links work within this model: the user provides their email, Tribe verifies it computes to the correct pseudonymous ID, sends a branded email, and discards the address. The email is never stored — it’s used transiently each time.
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.