nips/97.md

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:
```json
{
  "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.