Authentication methods
Fanzava supports multiple authentication methods for participants, configurable per hub. Enterprise SSO is documented separately on the SSO page; this page covers the methods available to all plans.
For a summary you can forward to your IT team, see security at Fanzava.
Methods overview
Section titled “Methods overview”| Method | Availability | Use case |
|---|---|---|
| Email + password | All plans | Default for participants without organisational SSO |
| Magic link (passwordless email) | All plans | Reduces password reset friction; recommended for casual hubs |
| All plans, on by default | Social sign-in for participants with Google accounts | |
| Microsoft | All plans, on by default | Social sign-in for work, school and personal Microsoft accounts |
| Apple, Facebook | All plans, with your own developer credentials | Social sign-in under your own app |
| Enterprise SSO (SAML / OIDC / OAuth) | Enterprise | Organisational identity provider; see SSO |
Hub admins turn each method on or off from Settings → Login methods in the hub admin. A method that is off is not shown on your sign-in page and is refused if anyone tries it directly.
Email and password
Section titled “Email and password”Password storage
Section titled “Password storage”Passwords are hashed with Argon2id, the recommended algorithm under OWASP guidance and a winner of the Password Hashing Competition. Argon2id is memory-hard, making large-scale brute-force attacks computationally expensive even against captured hashes.
Passwords are never stored in plaintext, never transmitted other than over TLS 1.3, and never logged. The hashes themselves are not reversible.
Password policy
Section titled “Password policy”The default password policy aligns with NIST SP 800-63B:
- Minimum length: 10 characters
- No mandatory character class rules (NIST guidance recommends against complexity rules that drive predictable substitutions)
- Checked against the Have I Been Pwned breach corpus: known-breached passwords are rejected
- No mandatory expiry: passwords are rotated only on suspected compromise (also per NIST)
Hub admins on Enterprise plans can configure stricter policies (longer minimums, mandatory complexity rules, periodic expiry) from Admin → Settings → Security → Password policy.
Bot protection
Section titled “Bot protection”Cloudflare Turnstile is deployed on the sign-in, sign-up, password reset, and magic-link request flows. Turnstile is a privacy-preserving CAPTCHA alternative that runs entirely client-side, blocking automated traffic without tracking users or showing image puzzles.
Rate limits and account lockout
Section titled “Rate limits and account lockout”Authentication endpoints are rate-limited per IP and per email:
- Sign-in attempts: 10 per minute per IP
- Password reset requests: 3 per hour per IP+email combination
- MFA challenges: 5 attempts per 15 minutes per user
After repeated failed sign-in attempts, the affected account is locked for a short period (default 15 minutes; configurable on Enterprise). The locked-out user receives an email notification.
For the full rate-limit table, see Application & edge security.
Magic link
Section titled “Magic link”When enabled, participants sign in by entering only their email address. Fanzava sends a single-use link that expires after 10 minutes. The user clicks the link, authenticates, and is signed in, no password involved.
Magic links:
- Are single-use: once clicked, the same link cannot authenticate again
- Expire after 10 minutes
- Are bound to the email address and IP that requested them (mismatch rejects the request)
- Are rate-limited per email (3 requests per hour)
Magic links can be used alongside passwords or in place of them. For hubs where participants are unlikely to engage with frequent password resets, magic-link-only authentication can be enabled to remove passwords from the flow entirely.
Google and Microsoft
Section titled “Google and Microsoft”Participants can sign in with a Google or Microsoft account. Both are on by default for every hub.
By default they run on Fanzava’s own Google and Microsoft apps. When a participant signs in, Google or Microsoft shows a consent screen, and that screen names the app the sign-in belongs to: by default, Fanzava. Google and Microsoft are listed as sub-processors for this reason.
If you run a white-label hub and do not want our name on that screen, you have two options in Settings → Login methods:
- Turn it off. Google or Microsoft sign-in disappears from your sign-in page. Participants sign in with whichever other method your hub offers. On a hub where SSO is required, that is your identity provider, not a password or magic link.
- Add your own developer credentials. Enter the client ID and secret from your own Google or Microsoft app. Participants then see your app’s name, not ours. Turning the method off keeps your credentials, so you can turn it back on later without re-entering them.
The client secret is encrypted when you save it and is never shown again. To replace it, enter a new one.
Apple and Facebook
Section titled “Apple and Facebook”Apple and Facebook sign-in are off by default and only run on your own developer credentials. Turn either on in Settings → Login methods by entering your app’s client ID and secret.
Authentication architecture
Section titled “Authentication architecture”Fanzava’s authentication layer is a pluggable adapter pattern. The default adapter is Better Auth, an open-source TypeScript authentication library. Enterprise customers can use WorkOS for SAML/OIDC/OAuth-based SSO, with Clerk and Auth0 also supported as alternative adapters.
The pluggable design means:
- A single hub can support multiple authentication methods simultaneously
- Switching auth providers does not require rebuilding the application
- Custom requirements (on-premise IdP, regional identity providers) can be accommodated without changes to participant-facing flows
For implementation detail of the adapter pattern, Enterprise customers can request the architectural review document from their account manager.