Add granular per-endpoint API key permissions#144
Open
benthecarman wants to merge 2 commits intolightningdevkit:mainfrom
Open
Add granular per-endpoint API key permissions#144benthecarman wants to merge 2 commits intolightningdevkit:mainfrom
benthecarman wants to merge 2 commits intolightningdevkit:mainfrom
Conversation
|
👋 Thanks for assigning @tnull as a reviewer! |
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.