Proposal: Secure, Persistent JWT/HTTPS Token Authentication for Custom ComfyUI Servers

[TheModdersDen]

Problem Description

Many users deploy remote ComfyUI instances or endpoints behind secure reverse proxies, API gateways, or authentication providers (e.g., Cloudflare Access, Authelia, NGINX Basic/Bearer auth, etc.) that require a token or JWT to access both HTTP endpoints and WebSocket connections.
Currently, the plugin lacks a dedicated, persistent interface in the settings UI to supply an authorization token for custom servers. If a remote setup requires token-based authentication, users have to manually configure headers or re-enter details, which lacks persistence and leads to security exposures.

Proposed Solution

I propose adding secure, persistent JWT/Bearer token authentication support for Custom Servers with the following architecture:

1. User Interface Integration:
   • Add a masked password field (QLineEdit.Password) labeled Authorization Token under the Custom Server configuration layout.
2. Secure Storage (Zero Plaintext on Disk):
   • Ensure the token is never stored in plaintext inside settings.json (where it is saved as an empty string "").
   • Delegate storage to the native OS keyring/credential store to use high-entropy, OS-level symmetric encryption:
     • Windows: Windows Credential Manager via native advapi32.dll (CredWriteW/CredReadW via ctypes).
     • macOS: macOS Keychain via the standard /usr/bin/security tool).
     • Linux: Linux Secret Service via the secret-tool CLI from libsecret).
   • No External Dependencies: Use the third-party keyring package if available, but include native fallbacks (ctypes and subprocess CLI wrappers) so the credential storage works out-of-the-box in Krita's embedded Python interpreter without requiring users to run pip install. No machine-id or hardware UUIDs are read.
3. HTTP and WebSocket Client Authentication:
   • Update RequestManager to automatically inject the token as a Bearer token header (Authorization: Bearer <token>) on all HTTP requests.
   • Update ComfyClient to inject the same token during the WebSocket connection upgrade handshake via additional_headers.
4. Redaction in Logs:
   • Ensure the token is redacted in system debug/diagnostics dumps (e.g., model/root.py logs).

Implementation Details

I have prepared and tested changes covering:

• ai_diffusion/secure_storage.py [NEW]: The secure storage helper managing OS keychain operations and fallback checks.
• ai_diffusion/settings.py: Intercepts save() and load() to direct the server_authorization setting to secure storage, keeping settings.json secure.
• ai_diffusion/ui/settings.py: Adds the server_authorization password-echo input field to the settings tab UI.
• ai_diffusion/model/connection.py: Passes the decrypted token to the client.
• ai_diffusion/backend/comfy_client.py: Injects the token into HTTP client headers and WebSocket handshakes.
• tests/test_secure_storage.py & tests/test_auth.py [NEW]: Thorough unit tests covering local keyrings, mock overrides, HTTP auth injection, and WebSocket handshake arguments.
• docs/src/content/docs/authentication.mdx [NEW]: Comprehensive user-facing documentation integrated directly into the Astro Starlight handbook.

Benefits

• Improved Security: No plain-text passwords or secret keys saved in settings.json.
• Better Usability: Tokens are entered once and automatically persist across Krita sessions, updates, and plugin reloads.
• Enterprise-ready Connections: Allows seamless integration with authenticated cloud servers and secure proxy architectures.

And the best part? It's already coded. See for yourself here: https://github.com/TheModdersDen/krita-ai-diffusion/tree/feat/better-auth-handling

I'm open to suggestions/changes to this codebase, but I've basically gotten tired of having to hand-code in the auth code every time this plugin updates (thus breaking my code). I feel it's time it is officially added into the plugin.

[Acly]

Isn't there a setting already that injects a bearer token? It doesn't have UI, but I don't understand why you have to change code after every update, the token should persist in settings.json and continue working.

I'm okay with adding UI to enter the token, just needs to be clear that it's optional so people with local servers (by far the most common) aren't confused.

I'm not convinced it's necessary to add all the complexity and platform-dependent code to for credential storage (and all the other LLM bloat) with reliance on command line tools, these things are likely to break and hard to reproduce. Storing plain text is not ideal but I don't see a big enough threat here.

[TheModdersDen]

Thanks for getting back to me!

While I have seen discussion of adding auth by hand (similar to what I've had to do, see here for instance) and even a PR that was abandoned sometime ago (Specifically PR#1295), I haven't found an actual method to input a bearer token into the auth system that is persistent.

I noticed that there's a value (in the settings.json file called access_token), but it doesn't seem to register correctly with either modern ComfyUI-Login or my own auth system (which I built specifically for the purpose of protecting public-facing ComfyUI instances, while still making them accessible and usable).

Regarding the 'platform specific' stuff, I can strip that out, should you want, and can also add plaintext obfuscation (or better encryption) before submitting a PR.

Looking forward to further coordination and getting this implemented (potentially). 😄
//TheModdersDen