Notification widget auth modes
Authentication controls how the Notification Center widget identifies the current user to Notifizz. Notifizz supports four modes, three of which are picked at the call site viaauthType. The fourth, PubliclySignedJwt, is configured server-side via the dashboard.
TL;DR
- Three SDK-exposed modes —
firebase,backendToken,none(dev-only). Pick at the call site. - One dashboard-configured mode —
PubliclySignedJwt. No SDK shorthand. The dashboard wires a JWKS URL + claims, and the widget authenticates transparently from your existing identity-provider session. - Production uses
firebase,backendToken, orPubliclySignedJwt.noneis dev-only.
The four modes
| Mode | SDK authType value | Identity source | Backend work |
|---|---|---|---|
| Firebase | 'firebase' | Firebase JWKS | none |
| Backend Token | 'backendToken' | HMAC vs authSecretKey | generate hashed token |
| Publicly-Signed JWT | n/a (server-side) | Provider JWKS (Auth0, Clerk, Cognito, Supabase, …) | configure JWKS URL in dashboard |
| None | 'none' | not verified | none |
SDK type union
Across all three frontend SDKs (@notifizz/react, @notifizz/angular, @notifizz/vanilla), the call-site type is:
PubliclySignedJwt deliberately does not appear here — keeping the SDK surface minimal lets operators swap the strategy without a frontend deploy.
In the backend codebase the publicly-signed-JWT strategy is named
CustomRsaJwt. Same mode, different name. Customer-facing docs always say PubliclySignedJwt; you may see CustomRsaJwt once in dashboard logs and internal tools.Common SDK fields
All three frontend SDKs accept the same authentication fields:| Option | Type | Required | Description |
|---|---|---|---|
apiKey | string | always | Front API Key from the dashboard. |
authType | 'firebase' | 'backendToken' | 'none' | always | The SDK-exposed strategy. |
token | string | for firebase, backendToken | Auth token. |
userId | string | for backendToken, none | The user’s stable, opaque id — the value recipients are matched against for inbox delivery. Use your internal id, not the email (the email goes in userEmail). |
userEmail | string | for backendToken, none | The user’s email address. |
PubliclySignedJwt, the widget reads the JWT from your existing identity-provider session — no SDK fields beyond apiKey are required from your code.
Pick a mode
Firebase
Zero-work if you already use Firebase Auth — pass the ID token straight to the widget.
Backend Token
Recommended for custom auth systems — your backend HMAC-signs a token per user.
Publicly-Signed JWT
Auth0, Clerk, Cognito, Supabase Auth — configured in the dashboard.
No authentication
Local development only — never ship to production.
FAQ
Which mode should I pick first?
Which mode should I pick first?
If you already use Firebase Auth, pick Firebase — it’s a one-line frontend change. Otherwise pick Backend Token — it’s the standard “I have my own auth” path. If you use a managed identity provider (Auth0, Clerk, Cognito, Supabase Auth), Publicly-Signed JWT is the better long-term choice but requires dashboard setup.
Why isn't `PubliclySignedJwt` in the SDK type?
Why isn't `PubliclySignedJwt` in the SDK type?
Because the strategy is decided per-environment and changing it shouldn’t require a frontend deploy. The dashboard owns the JWKS URL, expected issuer, and expected audience — your code just initialises the widget. This keeps the SDK surface to three options and pushes config decisions to operators rather than developers.
I see `CustomRsaJwt` in the dashboard logs.
I see `CustomRsaJwt` in the dashboard logs.
Same thing as
PubliclySignedJwt — the backend originally named the strategy CustomRsaJwt and the rename hasn’t propagated everywhere. Treat them as identical.Can I switch modes without a frontend redeploy?
Can I switch modes without a frontend redeploy?
Between
firebase / backendToken / none — no, those are explicit authType values in your call site. Between any SDK mode and PubliclySignedJwt — yes, since PubliclySignedJwt is server-side. Many teams ship backendToken initially and switch to PubliclySignedJwt later.`backendToken` vs `PubliclySignedJwt` — security trade-off?
`backendToken` vs `PubliclySignedJwt` — security trade-off?
Both are cryptographically strong.
backendToken requires your backend to be online to mint tokens; PubliclySignedJwt decouples Notifizz from your backend (the widget verifies against the provider’s JWKS). Pick PubliclySignedJwt if you want widget auth to keep working through partial backend outages, or to reduce the surface area of your authSecretKey.Do I really have to use `none` in production for cost reasons?
Do I really have to use `none` in production for cost reasons?
No —
firebase, backendToken, and PubliclySignedJwt add zero per-call cost. The only reason to use none is local development. Anyone with the API key and a userId can read that user’s inbox in none mode — never ship it to production.See also
Authentication concept
The four-mode model in conceptual terms.
Backend tokens
client.generateHashedToken() end-to-end.Firebase auth
Pass a Firebase ID token to the widget.
Publicly-signed JWT
Auth0 / Clerk / Cognito / Supabase setup.