NIP-98: HTTP Auth
Nostr keys also need to talk to HTTP services
Nostr is built around signed events and relay messages, but many real services still run over HTTP: upload servers, relay admin endpoints, app APIs, account tools and web dashboards. NIP-98 gives those services a way to authenticate a Nostr user without creating a separate password account.
The user signs a kind 27235 event. The event includes the absolute URL in a u tag and the HTTP method in a method tag. The serialized event is base64 encoded into an Authorization: Nostr header.
The server verifies the signature, freshness, URL and method. For requests with bodies, a payload tag can bind a SHA-256 hash of the body.
A signed request envelope with a short lifetime
The NIP's checks are deliberately concrete: kind must be 27235, created_at needs to be within a reasonable window, the u tag must exactly match the request URL including query parameters, and the method tag must match the HTTP method.
If validation fails, the server needs to return 401 Unauthorized. The server may add its own checks, such as accepted domains, rate limits or pubkey allowlists.
The exact URL matching rule is the heart of the security model. A signature for one endpoint must not become a bearer token for another.
Kieran added the simple HTTP bridge in April 2023
Kieran added NIP-98 in April 2023, then quickly added the payload-hash note and small clarifications. Daniel Cadenas fixed the Authorization header string in December 2023. Since then, the file has been relatively stable compared with the newer app-layer NIPs.
That stability explains why NIP-98 appears as a dependency elsewhere. NIP-96 requires it for upload plans. Grain documents NIP-86-style relay management as gated by NIP-98. Developers have also experimented with Nostr login plugins for web auth.
It is a compact standard, but it sits at a sensitive boundary: Nostr identity meeting normal web infrastructure.
Replay prevention is the whole game
A server needs to enforce a short freshness window, compare the URL exactly and verify payload hashes for body requests when present. A client needs to sign only the exact request being made and avoid reusing events.
Browser extensions and remote signers needs to show enough context that users know what they are authorizing. Signing an HTTP auth event for a file upload is different from signing one for a relay admin action.
NIP-98 is not an OAuth replacement by itself. It is the primitive that a service can build into a larger session, capability or request policy.
A stale or broad signature becomes a web security bug
If a service accepts old timestamps, ignores query parameters or fails to check the method, a signed event can be replayed or misused. The NIP is simple, but implementation mistakes are security-critical.
User interfaces also need care. A signer that asks users to approve unreadable blobs trains them to sign dangerous requests.
Read NIP-98 in the wild
NIP-98 lets a Nostr key authorize an HTTP request. It is a clean bridge between signed identity and web services without issuing a normal platform password.
The security is in the binding. Method, URL, timestamp and payload hash decide whether the signature proves this request or becomes replay material. Small implementation mistakes become serious.
What changes when you actually use it
For you, NIP-98: HTTP Auth is felt when identity stops being a username and becomes authority. A client, signer, name, proof or auth event may look like account plumbing, but it decides who can publish, approve, connect, recover or be recognized. Read NIP-01 and the adjacent source links beside it so you can tell the difference between a convenient identity surface and the key material that actually controls the account.
What changes for builders and operators
For builders, NIP-98: HTTP Auth means making authority visible before action. A signer prompt, name proof, delegation, encrypted key, external identity or HTTP auth event needs plain language around scope, expiry, destination and recovery. If a person has to guess what they are authorizing, the protocol has already lost the trust battle.
What the official file makes concrete
The official file is organized around Nostr event, Request Flow, Reference Implementations. Inspect kind 27235, draft, content, u, method, kind, created_at, payload because these are the pieces most likely to surface as product behavior.
NIP-98: HTTP Auth is an authority path, not decoration. A name, key, signer, delegation or auth event decides who can act as you.
Where it breaks
The failure mode in NIP-98: HTTP Auth is authority drift. A name resolves to an old key, a signer approves too broadly, an auth event gets replayed, a delegation lasts too long or a private key backup gives false comfort. The product has to keep control boundaries visible after onboarding, not only during setup.
Where this appears outside the markdown
In the ecosystem, NIP-98: HTTP Auth usually appears at the doorway: account setup, profile recognition, signer approval, cross-platform proof, remote signing, HTTP auth or recovery. That doorway needs unusually clear language because identity mistakes are sticky. Once a key, signer or proof is trusted in the wrong place, every later feature inherits the confusion.
The nearby-standard trap
The nearby-standard trap in NIP-98: HTTP Auth is confusing recognition with control. A name, signer, URI, encrypted key, delegation or auth signature may all sit near identity, but they answer different questions. Read NIP-01 and the adjacent source links and ask one thing each time: who can act, who can verify, and what can be revoked?
Language that keeps the feature honest
Good product copy for NIP-98: HTTP Auth names the authority. It says whether you are sharing a public key, approving a signature, trusting a domain, exporting an encrypted secret, delegating power or authenticating to a service. Small labels matter because identity mistakes do not feel small after they happen.
What this page does not promise
NIP-98: HTTP Auth does not make identity effortless or risk-free. It can help keys, names, signers, delegation or authentication become portable, but it cannot decide who you trust, how you back up secrets or whether a domain, app or signer deserves authority. Read NIP-01 and the adjacent source links as a control map before handing any interface the power to sign, verify or speak for you.
Read it as a field test
Start NIP-98: HTTP Auth with the moment of authority: signing, naming, delegation, authentication, encryption or recovery. Then ask which key or service can act. The source terms kind 27235, draft, content, u, method, kind are useful because they turn vague identity language into concrete control points. Without that, a friendly login screen can hide the most important security decision.
Where the standard earns trust
The source links give you places to test the interpretation in public: nips.nostr.com NIP-98, NostrAuth.cs reference, Grain API docs, NIP-96 HTTP File Storage. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-98 source is the anchor for exact wording, and NIP-98 commit history shows how that wording moved over time. The strongest secondary clues here are nips.nostr.com NIP-98, NostrAuth.cs reference, Grain API docs. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-98: HTTP Auth: first the human promise, then kind 27235, draft, content, u, method, kind, then the implementation record, then the real-world failure case. That order keeps NIP-98 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who gains authority when this NIP is used: your key, a signer, a domain, a delegated key, a wallet or a web service?
- Can you revoke, rotate, back up or inspect that authority before something goes wrong?
- Does the interface separate public recognition from private signing power in language you can act on?
What to verify before you rely on it
- Find
kind 27235,draft,content,u,methodin the official file and check where the UI exposes the same concept. - Read NIP-01 and the adjacent source links as context before treating NIP-98 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-98: HTTP Auth in that order: Official NIP-98 source for the current wording; NIP-98 commit history for the change record; nips.nostr.com NIP-98, NostrAuth.cs reference, Grain API docs for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
