Skip to main content

​
No-authentication widget mode

authType: "none" lets the widget connect with only a userId and userEmail, with no server-side identity verification. It’s the fastest way to wire up the widget while building — and a serious foot-gun in production.
This mode does not verify the user’s identity. Anyone with the API key and a userId can connect as that user and read their notifications. Do not use this in production under any circumstances.

​
TL;DR

  • authType: "none" skips token verification entirely.
  • Use it for local development, demos, hackathons, internal sandboxes — never production.
  • Migrate to backendToken, firebase, or PubliclySignedJwt before shipping.

​
Setup

<NotifizzInbox
  options={{
    apiKey: "YOUR_FRONT_API_KEY",
    authType: "none",
    userId: "u_42",
    userEmail: "alice@example.com",
  }}
/>

​
Required fields

FieldTypeDescription
authType'none'Mandatory literal.
userIdstringThe user’s unique identifier — used as the inbox key.
userEmailstringThe user’s email address.

​
When to use

none mode is appropriate for:
  • Local development — the fastest way to test the full track → orchestrator → widget loop without setting up backend token generation or Firebase.
  • Demos and hackathons — when you need a working widget in five minutes.
  • Internal sandboxes behind your VPN — when the threat model is “honest insiders only”.
It is never appropriate for:
  • Anything customer-facing.
  • Anything where the inbox content is sensitive (transactional, financial, health, …).
  • Anything connected to a production-shaped database.

​
Migrating to production

Pick a real auth mode before going live:

Backend tokens

Recommended if you have your own auth system.

Firebase

Zero backend work if you already use Firebase Auth.

Publicly-signed JWT

Auth0, Clerk, Cognito, Supabase Auth — dashboard-configured.

Authentication overview

The four-mode comparison.
The migration is one-line on the frontend (change authType and pass token), plus whatever backend setup the new mode requires.

​
FAQ

Not enforced server-side — the backend accepts none mode regardless of environment. The protection is conventional: don’t use it in production. Some teams add a CI/lint rule that fails the build if authType: "none" ships to a production-tagged config.
Nothing — that’s exactly the trade-off. The Front API Key plus a userId is enough to read that user’s inbox. If your API Key leaks (it’s a public key by design, embedded in your frontend bundle), none mode means anyone can browse any user’s notifications.
Yes — and you should. Use a dev-only Front API Key in your dev environment with none mode allowed; use a prod Front API Key with only firebase / backendToken / PubliclySignedJwt strategies wired in the dashboard. The keys are environment-scoped, so a leaked dev key only reveals the dev inbox.
Because it’s only the local widget that “works” — there is no server-side identity check, so the connection is wide open. Production usage means the inbox is owned by an attacker the moment they discover the API key.
It’s used for display purposes inside the widget (the dropdown header sometimes shows the email). It is not verified against anything. The orchestrator can still target by userId, so passing a wrong email doesn’t break delivery — just display.

​
See also

Authentication overview

The four-mode model and when to pick each.

Frontend quickstart

Render the widget in five minutes.