Know which backend you are authenticating to

Nostr WoT separates permission to use your identity on a website from permission to authenticate that identity to an HTTP service. A website and its API can live on different domains. The approval must describe the service receiving the proof, not assume that it is the website in your address bar.

This guide covers Nostr WoT.

For WebSocket relay authentication, read the separate relay authentication guide.

Exact approvals and optional automatic authentication

A website such as https://client.example can legitimately use https://api.client.example. A remembered HTTP approval binds the active account, requesting website origin, exact signed URL including query text, and HTTP method. It does not authorize another endpoint, method, site or account. Older origin-wide allows require fresh consent; saved denials remain effective.

Default backend auth starts off for each account. When enabled in Permissions, connected sites can use NIP-98 automatically for the exact same HTTPS origin or an exact website/backend pair marked nip98 in the registry and policy rules. This covers valid paths and methods at those origins. Listing a client alone is insufficient; unverified entries and wildcard domains do not qualify. Explicit denials win. Relays have separate permissions.

Review and manage backend authentication

Prompts show the requesting website, destination and method. Approve and Deny affect only that request. Arrow menus remember a decision for the exact account/site/URL/method. The code icon opens the raw event. Generic bulk signing approval does not grant standing authentication permission.

Open Permissions → Backend authentication. When the default policy is enabled, a notice explains its scope and links to the rules and registry. Automatic policy approvals do not create saved rows, so an empty table does not mean automatic authentication is disabled. The table lists explicit saved backend decisions for the active account.

Revoke a saved entry there, or disable Default backend auth in Permissions to stop policy-based approvals. Turning it off leaves explicit saved grants intact. Revocation affects future signing, not proofs already sent or backend sessions already established. HTTP authentication has no all-sites grant.

What the extension verifies

The requester comes from browser-provided document identity, not a website's claimed origin parameter. Authentication requires a verified top-level frame; embedded frames, opaque origins and inconsistent document origins are refused. HTTPS is required outside explicit loopback development exceptions. An iframe cannot borrow a trusted parent's authentication permission.

The event parser rejects ambiguous required tags, invalid URLs, unexpected content and stale timestamps. Optional origin and client-origin tags must match the actual requesting origin. General signing permission does not bypass these authentication approvals. Site access, account-session validity and permissions are rechecked after waiting for approval or unlock.

With a NIP-46 bunker, the returned signature must belong to the expected account and match the approved event's kind, timestamp, content and ordered tags. A valid signature on a different event is rejected.

Extra protection for native wallet operations

The companion LNbits-proxy uses a stricter v2 contract for provisioning/recovering a wallet and claiming/releasing an address. These are privileged operations, not an ordinary website login. The extension's generic website signer refuses tokens for the native wallet service's sensitive management paths.

In the dedicated wallet flow, the proof binds the exact URL, method and hash of the exact request body. A backend-issued challenge lasts 60 seconds and can be consumed once. A separate transaction token travels in its own header; only its hash is signed. The server verifies these bindings and the signature before an atomic nonce consumption. Changing the operation body invalidates the proof.

Browser requests use an exact configured HTTPS origin allowlist and a matching signed client-origin value. The native flow still requires the proof and separate transaction token. Public LNURL discovery retains its separate policy. This is an application-specific contract, not a new requirement imposed on all Nostr APIs. The wire specification and rollout guide has the developer details. Deploy the compatible backend before publishing the extension: retired routes return HTTP 426, and the client deliberately does not downgrade.

What the proof establishes

NIP-98 binds a signed HTTP proof to its URL and method; a conforming backend must check those values. The wallet contract additionally requires body binding and one-use transactions. For other backends, the extension cannot force the server to validate correctly.

A proof for backend A should not be accepted by backend B. However, someone who holds a valid proof and any required transaction token can forward them to the intended backend before their first use. CORS restricts browsers; it cannot stop arbitrary server-to-server requests. An origin tag is not cryptographic browser attestation, since another signer could sign a false claim.

Likewise, malicious code running inside a trusted top-level site shares that site's authority. These controls reduce the scope of consent and reject concrete forms of substitution and replay; they do not promise to eliminate phishing, compromised sites, or every form of authentication forwarding.