> ## Documentation Index
> Fetch the complete documentation index at: https://notifizz.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Notification Widget — No Authentication (Dev Only)

> Connect the Notification Center widget without token verification — local development and demos only. Anyone with the API key can read any user's inbox.

# 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.

<Warning>
  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.
</Warning>

## 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

<Tabs>
  <Tab title="React">
    ```jsx theme={null}
    <NotifizzInbox
      options={{
        apiKey: "YOUR_FRONT_API_KEY",
        authType: "none",
        userId: "u_42",
        userEmail: "alice@example.com",
      }}
    />
    ```
  </Tab>

  <Tab title="Angular">
    ```html theme={null}
    <notifizz-bell
      [options]="{
        apiKey: 'YOUR_FRONT_API_KEY',
        authType: 'none',
        userId: 'u_42',
        userEmail: 'alice@example.com'
      }"
    ></notifizz-bell>
    ```
  </Tab>

  <Tab title="Vanilla JS">
    ```javascript theme={null}
    const notifizz = createNotifizz({
      apiKey: "YOUR_FRONT_API_KEY",
      authType: "none",
      userId: "u_42",
      userEmail: "alice@example.com",
    });

    notifizz.mount();
    ```
  </Tab>
</Tabs>

## Required fields

| Field       | Type     | Description                                           |
| ----------- | -------- | ----------------------------------------------------- |
| `authType`  | `'none'` | Mandatory literal.                                    |
| `userId`    | `string` | The user's unique identifier — used as the inbox key. |
| `userEmail` | `string` | The 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:

<CardGroup cols={2}>
  <Card title="Backend tokens" icon="lock" href="/docs/sdks/authentication/backend-tokens">
    Recommended if you have your own auth system.
  </Card>

  <Card title="Firebase" icon="fire" href="/docs/sdks/authentication/firebase">
    Zero backend work if you already use Firebase Auth.
  </Card>

  <Card title="Publicly-signed JWT" icon="shield" href="/docs/sdks/authentication/publicly-signed-jwt">
    Auth0, Clerk, Cognito, Supabase Auth — dashboard-configured.
  </Card>

  <Card title="Authentication overview" icon="key" href="/docs/sdks/authentication/overview">
    The four-mode comparison.
  </Card>
</CardGroup>

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

## FAQ

<AccordionGroup>
  <Accordion title="Is `none` mode disabled in production environments?">
    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.
  </Accordion>

  <Accordion title="What stops a malicious actor from impersonating a user in `none` mode?">
    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.
  </Accordion>

  <Accordion title="Can I scope `none` to a specific environment via separate API keys?">
    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.
  </Accordion>

  <Accordion title="The widget seems to work in `none` — why bother with the others?">
    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.
  </Accordion>

  <Accordion title="What does `userEmail` do in `none` mode?">
    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.
  </Accordion>
</AccordionGroup>

## See also

<CardGroup cols={2}>
  <Card title="Authentication overview" icon="key" href="/docs/sdks/authentication/overview">
    The four-mode model and when to pick each.
  </Card>

  <Card title="Frontend quickstart" icon="rocket" href="/docs/quickstart/frontend">
    Render the widget in five minutes.
  </Card>
</CardGroup>