Add granular per-endpoint API key permissions#144
Add granular per-endpoint API key permissions#144benthecarman wants to merge 2 commits intolightningdevkit:mainfrom
Conversation
|
👋 Hi! This PR is now in draft status. |
benthecarman
force-pushed
the
granular-api-keys
branch
2 times, most recently
from
ad7745b to
583437a
Compare
Change the auth header format from `HMAC <timestamp>:<hmac>` to `HMAC <key_id>:<timestamp>:<hmac>` where key_id is the first 8 bytes of SHA256(api_key), hex-encoded (16 chars). The server validates the key_id before computing the HMAC, enabling O(1) key lookup when multiple API keys are supported. The client precomputes the key_id at construction time. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace the single all-or-nothing API key with a directory-based system that supports multiple API keys with per-endpoint access control. API keys are stored as TOML files in `<network_dir>/api_keys/`, each specifying a hex key and a list of allowed endpoints (or "*" for admin). The legacy `api_key` file is auto-migrated on first startup. New RPC endpoints: - `CreateApiKey`: generates a new key with specified permissions (admin only), writes it to disk, and updates the in-memory store - `GetPermissions`: returns the allowed endpoints for the calling key (always accessible by any valid key) The in-memory key store is shared via Arc<RwLock> across all connections so keys created at runtime are immediately usable. File writes use atomic rename for crash safety. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
benthecarman
force-pushed
the
granular-api-keys
branch
from
583437a to
44f4d06
Compare
|
🔔 1st Reminder Hey @tnull! This PR has been waiting for your review. |
|
🔔 2nd Reminder Hey @tnull! This PR has been waiting for your review. |
|
🔔 3rd Reminder Hey @tnull! This PR has been waiting for your review. |
|
As discussed offline, we'll want to explore alternative approaches first. |
3 participants
Closes #140
Currently ldk-server's auth is binary, you either have full access or no access. This makes it difficult to give third-party applications (e.g. bots) access to a node without granting them the ability to send funds, force-close channels, or perform other sensitive operations.
This PR replaces the original single API key with a directory of multiple API keys with per-endpoint permissions. API keys are stored as toml files in <network_dir>/api_keys/, each specifying a hex key and allowed endpoints (or "*" for admin). Adds
create-api-keyandget-permissionsfor creating api keys and to get your current auth permissions. Added some migration code to move your current api key to the new location. We can remove this eventually but also we could just do without it for now as we our the only real users so far.To support multiple keys without iterating all of them on every request, the HMAC auth header is extended to include a key ID (HMAC
<key_id>:<timestamp>:<hmac>), where key_id is the first 8 bytes of SHA256(api_key) hex-encoded. This allows O(1) key lookup on the server side.