Skip to main content

​
Notification widget authentication

Authentication controls how the Notification Center widget identifies the current user to Notifizz. The right choice depends on your existing auth stack and your security requirements.

​
TL;DR

  • Four modes total: firebase, backendToken, none, and PubliclySignedJwt.
  • Three are SDK-exposed via authType: firebase, backendToken, none.
  • PubliclySignedJwt is dashboard-configured — no SDK shorthand. The widget picks it up from the server-side auth strategy attached to your environment.
  • Production must use firebase, backendToken, or PubliclySignedJwt. none is dev-only.

​
The four modes

​
Firebase Authentication

Best for: Apps already using Firebase Auth. The widget passes a Firebase ID token; Notifizz verifies it server-side against Firebase. 
{
  apiKey: "YOUR_FRONT_API_KEY",
  authType: "firebase",
  token: firebaseUser.idToken,
}
  • Where the token comes from — your Firebase client SDK after signInWith….
  • What Notifizz does — verifies the token’s signature against the project’s JWKS, extracts the user identity, scopes the widget session.
  • Backend work — none beyond what you already do for Firebase.
See the Firebase auth reference.

​
Backend Token

Best for: Apps with their own auth, no Firebase, security-sensitive notifications. Your backend uses the Notifizz Node SDK to generate a hashed token and ships it to the frontend along with the user identity: 
// Backend
const token = client.generateHashedToken("u_42");

// Frontend
{
  apiKey: "YOUR_FRONT_API_KEY",
  authType: "backendToken",
  token,
  userId: "u_42",
  userEmail: "alice@example.com",
}
  • What the token is — SHA-256(userId + authSecretKey), hex-encoded.
  • What Notifizz does — recomputes the hash with its server-side authSecretKey and compares.
  • Backend work — generate one token per user per session and ship it (typically alongside login response or via a dedicated endpoint).
See the backend tokens reference.

​
Publicly-Signed JWT

Best for: Apps using Auth0, Clerk, Cognito, Supabase Auth, or any provider that publishes a JWKS endpoint. The widget passes a JWT issued by your identity provider; Notifizz verifies it against a JWKS URL configured in the dashboard. Unlike the other three, this mode has no SDK shorthand — there’s no authType: "publiclySignedJwt" in the call site. Instead, the dashboard’s notificationCenterSetup dev-task wires the JWKS URL + expected issuer/audience claims, and the widget picks the strategy up server-side from your Front API Key.
In the backend codebase the strategy is called CustomRsaJwt — same mode, different name. Customer-facing prose always uses PubliclySignedJwt; the backend alias only surfaces in dashboard logs and a few internal tools. Don’t be surprised if you see it once.
When PubliclySignedJwt is the configured strategy, the widget reads the JWT from your existing identity provider session and passes it to Notifizz transparently — your call site looks like the other modes minus the authType field, since the strategy is server-side. See the publicly-signed JWT reference for the dashboard setup, required claims, and per-provider walkthroughs (Auth0 / Clerk / Cognito / Supabase Auth).

​
No authentication

Best for: Local development, demos, internal tools with no security needs. 
{
  apiKey: "YOUR_FRONT_API_KEY",
  authType: "none",
  userId: "u_42",
  userEmail: "alice@example.com",
}
authType: "none" does not verify the user. Anyone with the API key and a userId can read that user’s inbox. Never ship this to production.
See the no-auth reference.

​
Comparison

FirebaseBackend TokenPublicly-Signed JWTNone
Identity verificationFirebase JWKSHMAC + auth secretProvider JWKSNone
Backend worknonegenerate hashed tokenconfigure JWKS URL in dashboardnone
SDK authType value'firebase''backendToken'n/a (server-side)'none'
Required SDK fieldstokentoken, userId, userEmail(provider session)userId, userEmail
Best forFirebase appsCustom authAuth0 / Clerk / Cognito / Supabasedev only

​
SDK type union

Across all three frontend SDKs (@notifizz/react, @notifizz/angular, @notifizz/vanilla), the call-site type is: 
type AuthType = 'firebase' | 'backendToken' | 'none';
PubliclySignedJwt deliberately does not appear in this union — it’s reachable only through dashboard configuration so the SDK surface stays minimal and the strategy can be swapped without a frontend deploy.

​
FAQ

Because the strategy is decided per-environment and changing it shouldn’t require a frontend deploy. The dashboard owns the JWKS URL, expected issuer, expected audience — your code just initialises the widget and the strategy applies server-side. This also keeps the SDK surface to three options and pushes config decisions to the people who need them (operators, not developers).
Same thing as PubliclySignedJwt — the backend originally named the strategy CustomRsaJwt and the rename hasn’t propagated everywhere. Treat them as identical. Customer-facing prose uses PubliclySignedJwt.
Between firebase / backendToken / none — no, those are explicit authType values in your call site. Between any SDK mode and PubliclySignedJwt — yes, since PubliclySignedJwt is configured server-side. Many teams ship backendToken initially and switch to PubliclySignedJwt later.
On the backend, expose an authenticated endpoint that returns { token: client.generateHashedToken(userId), userId, userEmail }. On the frontend, mount the widget after that endpoint resolves and switch authType to backendToken. The transition is per-environment — keep none on dev if your team uses it for fast iteration.
The widget surfaces state.hasError = true with an error code. Refresh the token from your backend (or re-fetch the Firebase ID token) and re-mount the widget — there is no in-place re-auth today.
Destroy the current widget, mount a new one with the new identity. Across all three SDKs the pattern is the same: clear cached real-time state by destroying the instance, then create a fresh one with the new token + userId.

​
See also

Authentication overview (SDK)

The four-mode model with per-mode references.

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.