Comprueba en qué backend te estás autenticando

Permisos exactos y autenticación automática opcional

Una web como https://client.example puede usar https://api.client.example. Un permiso HTTP recordado vincula la cuenta activa, el origen solicitante, la URL firmada exacta con su consulta y el método HTTP. No autoriza otros destinos, métodos, sitios o cuentas. Las autorizaciones antiguas por origen requieren nuevo consentimiento; las denegaciones siguen vigentes.

Autenticación predeterminada de backend empieza desactivada por cuenta. Al activarla en Permisos, los sitios conectados pueden usar NIP-98 automáticamente con el mismo origen HTTPS exacto o un par web/backend marcado nip98 en el registro y sus reglas. Incluye rutas y métodos válidos en esos orígenes. Una entrada informativa, no verificada o con comodines no basta. Las denegaciones explícitas tienen prioridad. Los relays conservan permisos separados.

Revisar y gestionar la autenticación

La solicitud muestra web, destino y método. Aprobar y Denegar afectan solo a esa solicitud. Las flechas permiten recordar la decisión para esa cuenta, sitio, URL y método. El icono de código abre el evento completo. La aprobación masiva de firmas ordinarias no concede permisos permanentes de autenticación.

Abre Permisos → Autenticación del backend. Si la política está activada, un aviso explica su alcance y enlaza las reglas y el registro. Sus aprobaciones automáticas no crean filas: una tabla vacía no significa que la política esté desactivada. La tabla muestra decisiones explícitas guardadas para la cuenta activa.

Revoca una entrada allí o desactiva la política en Permisos. Desactivarla conserva los permisos explícitos. La revocación afecta a firmas futuras, no a pruebas enviadas ni sesiones ya creadas. HTTP no tiene permisos para todos los sitios.

Qué comprueba la extensión

El origen procede del documento identificado por el navegador, no de un parámetro elegido por la web. Se exige un marco principal verificado: los iframes, incluso del mismo origen, y los orígenes opacos o inconsistentes se rechazan. Se requiere HTTPS salvo excepciones explícitas de desarrollo en loopback.

Se rechazan etiquetas obligatorias ambiguas, URL inválidas, contenido inesperado y fechas caducadas. Las etiquetas opcionales origin y client-origin deben coincidir con el solicitante real. Tras esperar una aprobación o desbloqueo se vuelven a comprobar acceso, permisos y sesión de cuenta.

Con un firmante NIP-46, la firma debe corresponder a la cuenta esperada y al evento aprobado completo, incluidas las etiquetas en su orden original. Cambiar de cuenta invalida el trabajo anterior.

Operaciones de la cartera integrada

La creación o recuperación de carteras y la gestión de direcciones Lightning utilizan el protocolo v2 de LNbits-proxy. El firmante genérico de las webs rechaza tokens para esas rutas sensibles.

La prueba vincula URL, método y hash de los bytes exactos del cuerpo. El backend emite un desafío válido durante 60 segundos y de un solo uso. Un token de transacción separado viaja en su propia cabecera; se firma únicamente su hash. El servidor valida firma y valores antes de consumir el desafío de forma atómica. Para solicitudes del navegador también exige un origen HTTPS permitido y un client-origin firmado coincidente. Los endpoints antiguos responden 426 y el cliente no utiliza un protocolo anterior.

Límites de la protección

NIP-98 requiere que el backend compruebe URL y método. La extensión no puede obligar a otros servidores a validar correctamente. Quien posea una prueba válida y los tokens necesarios puede reenviarlos al destino previsto antes de su primer uso.

CORS limita a los navegadores, no las llamadas entre servidores. Una etiqueta de origen firmada no acredita criptográficamente al navegador. El código malicioso dentro de una web principal autorizada comparte su autoridad. Estas comprobaciones acotan el consentimiento; no eliminan todo phishing o reenvío de autenticaciones.

Consulta el contrato v2 y las pruebas de autenticación.