nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-09 22:09:06 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity
d9774ae961
nips/97.md
Semisol d9774ae961
NIP-97: add redirect URL
2024-04-29 23:52:43 +03:00

2.1 KiB
Raw Blame History

NIP-97

Login with Nostr

draft optional

This NIP defines a flow for applications to request from a user that they control a private key for. This enables logging into applications (such as paid relay/media hosting services) without having to use other flows which may be annoying to use or not available. (DM codes, NIP-07 extensions)

Login URI

A login URI is defined of the format nostr+login:<domain>:<challenge> where domain MUST be a valid DNS domain or .onion service. The challenge MUST only consist of A-Z a-z 0-9 _ - ..

This login URI can be presented as a clickable link, a QR code or a copyable string.

Login process

A client that wishes to log in to a service SHOULD display the domain associated with the service to the end user before allowing them to log in to prevent services showing a login string for another service.

After the user approves the login, the client should send a POST request to /.well-known/nostr/nip97 to the domain with the i query parameter set to the challenge and a valid NIP-98 authentication header present.

The response MUST be a JSON object, with the format:

{
  "status": <"success" or "error">,
  "message": <OPTIONAL string message to show user in the case of an error>,
  "redirect_url": <OPTIONAL redirect URL>
}

For redirect_url, this should be used to bring the user to where they were while initiating the login process (now with the login complete). This should be used in a way that is compatible with a different device being used to authorize the sign in than the one being logged in on. An example for this is checking if the sign in was attempted from this device with a cookie, if so, redirect the user to where wanted to log in, otherwise show a "continue on device" message.

The redirect_url SHOULD be shown to the user and in a way that indicates it will take the user back to the app, such as Return to website.

HTTPS should always be used except for .onion services, which should be contacted using HTTP.

Clients MAY or MAY NOT decide to implement support for .onion services.