LNURL-auth использует ключ входа, привязанный к домену сервиса, вместо одного общего идентификатора кошелька для всех сайтов. При этом сам сервис может узнавать повторные входы, а связывание аккаунтов и браузерная сессия позволяют сопоставить дополнительные сведения. Разделение ключей по доменам — конкретное свойство протокола, а не обещание невозможности связать действия пользователя.
Разберите один вход и отделите его от платежа
Спецификация авторизации LUD-04 описывает задачу сервиса, которую совместимый кошелёк подписывает специальным linking key. Сервис проверяет ответ и может использовать публичный linking key как идентификатор аккаунта. Передавать сайту сид-фразу или приватную часть этого ключа для обычного входа не требуется. Подпись подтверждает вход в рамках предусмотренного процесса.
Сам вид QR-кода ещё не определяет запрос. Кошелёк может встретить платёж, получение средств или авторизацию. При LNURL-auth до подтверждения прочитайте домен и действие входа. Неожиданная сумма к оплате либо просьба импортировать сид-фразу на сайте не должны восприниматься как обязательная часть авторизации. Сначала выясните, какое действие фактически предлагает интерфейс.
В руководстве Breez SDK показана нужная граница: разобрать запрос, вывести пользователю домен и действие, затем получить ключ и отправить ответ. Руководство описывает реализацию по LUD-04 и LUD-05. Оно не подтверждает, что у любого Lightning-кошелька совпадают кнопки и вообще есть поддержка такого входа: это проверяют для конкретного приложения.
Для ключа важен домен авторизации, а не название бренда
В LUD-05 для BIP32-кошельков в получении linking key участвует полное доменное имя сервиса. Поэтому смена поддомена авторизации способна изменить идентификатор. Смотрите на фактический домен обработчика входа. Он может отличаться от привычного названия бренда и от страницы, на которой расположена кнопка «Войти».
| Вымышленная ситуация | Какой вопрос возникает | Что проверить |
|---|---|---|
| Повторный вход на auth.shop.example с прежним совместимым кошельком | Сервис получает прежний ключ? | Сохранён ли первоначальный домен авторизации |
| Переезд с auth.shop.example на login.shop.example | Другой домен даст другой ключ? | Порядок переноса или связывания аккаунтов |
| Второй сайт использует собственный домен входа | Получит ли он отдельный ключ? | Фактический адрес обработчика и реализацию |
| Два бренда используют один сервер авторизации | Действительно ли границы доменов разные? | Не считать разные логотипы независимыми идентификаторами |
| Изменился путь страницы при прежнем домене входа | Изменилась ли граница ключа? | Не ожидать новый профиль только из-за другого URL страницы |
Имена в таблице условные и не описывают реальный сервис. На них видно, почему фраза «отдельный аккаунт для каждого сайта» недостаточно точна. Спецификация отдельно рекомендует сохранять выбранный поддомен авторизации. Если после переезда появился другой профиль, причина может относиться к сопоставлению идентификаторов, а не к исчезновению платежа Lightning или списанию средств.
Ключ входа не заменяет проверку профиля сервиса
Постоянный linking key позволяет одному сервису узнавать последующие входы. К этому идентификатору могут относиться история заказов, настройки и другие записи аккаунта. Если затем добавить email или связать ещё один кошелёк через настройки платформы, появляются намеренно созданные связи сверх изначального разделения по доменам. Их нужно оценивать как отдельный выбор пользователя.
Пример такого устройства есть в документации аккаунта LN Markets: к профилю с обычными реквизитами можно привязать один или несколько Lightning-кошельков. Это иллюстрация связи методов входа конкретного продукта. Она не является рекомендацией пользоваться платформой и не доказывает, что все сервисы LNURL-auth объединяют аккаунты по тем же правилам.
Ещё один слой — состояние браузера. Руководство MDN о cookies объясняет, как сессионные cookies помогают сайту узнавать последующие обращения вошедшего пользователя. Замена пароля на LNURL-auth сама по себе не отключает сессии и выбранные сайтом средства отслеживания. Политику хранения и использования сведений проверяйте отдельно, не выводя её из названия метода входа.
Почему одинаковая сид-фраза не гарантирует перенос входа
Идентификатор LNURL-auth зависит не только от домена, но и от способа получения ключей кошельком. LUD-04 отмечает различия форматов начальных данных и устройства приложений. Успешное восстановление денежного баланса в другой программе ещё не доказывает, что она получила прежний linking key. Универсальную совместимость нельзя предполагать только по наличию слова Lightning в описании.
Есть отдельная спецификация LUD-13 на основе signMessage для кошельков без того же интерфейса доступа к мастер-ключу. Её чувствительные внутренние данные получения ключей не предназначены для передачи как реквизиты входа. Пользуйтесь поддерживаемой авторизацией кошелька. Не подписывайте и не раскрывайте произвольное сообщение, представленное посторонним сайтом как способ «починить идентификатор».
Справка The Bitcoin Company предупреждает о потере доступа к профилю при утрате ключа кошелька без запасного входа. Конкретные меню и доступность альтернативных способов зависят от продукта. До удаления единственного рабочего кошелька или старой установки проверьте текущий порядок восстановления именно в нужном сервисе, а не в инструкции соседней платформы.
Проверка приватности и восстановления до перехода
- Убедитесь, что сервис и кошелёк поддерживают LNURL-auth. Платёжный Lightning-адрес не подтверждает наличие авторизации.
- Прочитайте домен и действие в доверенном кошельке. Подтверждайте только тот вход или привязку, которые намеренно начали.
- Проверьте дополнительные данные профиля и связи с email, другими кошельками и идентификаторами.
- Зафиксируйте исходное приложение и его требования к резервной копии. Не включайте приватные данные в сообщения поддержке.
- Перед сменой программы проверьте доступ поддерживаемым способом, пока старый вход ещё работает.
- Если появился другой профиль, сравните домен, получение ключей и связи аккаунтов до вывода о пропаже денег или удалении учётной записи.
При проблеме входа поддержке пригодятся публичный домен сервиса, версия кошелька, примерное время и запрошенное действие. Сид-фраза, приватные данные получения ключей и случайный запрос на подпись не заменяют поддерживаемое восстановление. Авторизацию также отделяйте от квитанций перевода: успешный вход не доказывает оплату, а оплаченный инвойс — управление посторонним аккаунтом сайта.
Если вопрос относится к платежу, прочитайте отдельный разбор Lightning Address и LNURL. Обмен без регистрации KOT.CASH устроен как другой процесс, описанный в разделе как это работает. Материал не утверждает, что KOT.CASH предлагает LNURL-auth или принимает код авторизации как реквизиты выплаты по обменной заявке.
Частые вопросы
LNURL-auth использует один ключ входа на всех сайтах?
Предусмотренное получение ключей учитывает домен сервиса и создаёт отдельный linking key для него. Общий домен авторизации и намеренные связи аккаунтов оценивают с учётом фактического устройства платформ.
Передаёт ли вход LNURL-auth сид-фразу кошелька?
Обычный ответ авторизации содержит публичный linking key и подпись, а не сид-фразу. Просьба набрать сид-фразу на сайте относится к другому действию за пределами такого входа.
Сохранится вход LNURL-auth после смены Lightning-кошелька?
Это зависит от совместимости получения ключей, резервных данных и домена сервиса. Проверьте поддерживаемый перенос до удаления кошелька, через который пока удаётся войти.
По теме на сайте
Источники
- github.com/lnurl/luds/blob/luds/04.md
- github.com/lnurl/luds/blob/luds/05.md
- github.com/lnurl/luds/blob/luds/13.md
- sdk-doc-spark.breez.technology/guide/lnurl_auth.html
- docs.lnmarkets.com/en/account/
- developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies
- intercom.help/thebitcoincompany/en/articles/8064892-how-do-i-use-lightning-authentication-lnurl-auth