Hyperledger Besu JSON-RPC authentication and identity guide

Hyperledger Besu JSON-RPC authentication: who can call your node APIs

If your permissioned Besu network must limit node APIs to named people and services, know this first: Besu can validate a username and password credentials file or a JWT against a public key on its own, but it does not terminate HTTPS natively. Identity integration is therefore a design task that spans three components: the Besu node, a TLS-terminating proxy in front of it, and the identity provider that issues tokens. Each component must agree on who the caller is, how the call is encrypted, and which methods the caller may invoke.

Start with the token signing algorithm. Besu validates externally issued JWTs against a public key using RS256, RS384, RS512, ES256, ES384 or ES512. Confirm with the identity provider which algorithm it signs with, and confirm that the public key file on each node matches the active signing key. Key rotation is the harder part. Your identity provider will rotate signing keys on its own schedule, but the node reads a key file you manage. Plan the rotation so the new public key reaches every node before tokens signed with it arrive, and confirm in the Besu version you run whether a key change needs a restart.

Authentication tells Besu who is calling, not what that caller may do. A credentials file gives you usernames and passwords but no role model to speak of, and a JWT carries only the claims your identity provider puts in it. You must decide which users or service identities may call sensitive namespaces such as admin, debug, miner and transaction pool methods, and enforce that decision either in the proxy with a method allowlist or in node configuration. Map each group in your identity provider to a short list of methods, then test the mapping with negative requests from every role.

Keep validator access separate from RPC access. Validators accept peer connections for consensus and should not serve general API traffic, so place user-facing RPC on dedicated nodes that the proxy fronts. Treat the credentials file and the JWT public key as configuration with an owner, a change process and an audit trail. The node private key file is not encrypted by Besu, so anyone with read access to a validator host can impersonate that validator. Hardware-backed key storage through a security module plugin is a separate control, covered in the security hardening section.

Before go-live, confirm five points: the signing algorithm and key rotation procedure, the claim-to-method mapping, the proxy configuration for TLS and method filtering, the separation of validator and RPC nodes, and the logging that records which identity made each call. Ask your identity provider and your Besu support contact to confirm the authentication options and claim handling for your exact release, because the supported options are version-dependent. A test plan with both allowed and denied calls for each role gives your security team evidence that the controls work as designed.

Which Besu settings and outside components control API access

API access to a Besu node is decided by several layers working in sequence: the gateway in front of the node, Besu's own JSON-RPC authentication, and the permissions files that govern the network and accounts. The identity provider sits outside all three and decides who receives a token in the first place. Confirm exact option names against the authentication documentation for your Besu version before you write configuration.

Username and password credentials file

Besu's simplest JSON-RPC authentication option reads user names and password hashes from a credentials file that the node loads at startup. It gives each operator or service a named login, but it does not connect to your corporate directory, so every change to a user means editing and redistributing the file. Check who can read the file, how it is provisioned and rotated, and whether your security policy allows static credentials for the APIs you expose.

Externally issued JWTs with a public key

Besu can validate JSON Web Tokens that an external system issued, using a public key it holds locally. The documentation lists RS256, RS384, RS512, ES256, ES384 and ES512 as supported signing algorithms. Confirm which algorithms your identity provider signs with, how the public key is distributed and rotated, and which token claims Besu checks, since a mismatch will reject every call.

Node and account permissions files

Local permissioning uses two configuration files on each node. The node permissions file controls which peers may connect, and the account permissions file controls which accounts may transact, be onboarded or be suspended. These files restrict network-level and account-level actions, not API callers, so they complement JSON-RPC authentication rather than replacing it. Plan how changes are distributed to every node, because each node enforces its own copy.

TLS-terminating reverse proxy or gateway

Besu does not terminate HTTPS itself, so a reverse proxy or API gateway in front of each node must handle TLS, certificate management and, usually, connection limits and source filtering. This layer is where you block direct access to the JSON-RPC port from outside the trusted network. Verify that the gateway forwards the Authorization header unchanged, and that the node's RPC port is not reachable except through the gateway.

External identity provider

The identity provider authenticates people and services and issues the tokens that Besu validates. It is outside the Besu node but determines who can obtain access, how quickly access is revoked and which claims identify a caller. Decide whether tokens are issued to human operators, to applications or to both, set token lifetimes that match your policy, and confirm that the provider can publish or rotate the signing key used for validation.

Request path from client to permission check

A typical call starts with a client that presents a token or credential to the gateway. The gateway terminates TLS and forwards the request to the Besu node, which validates the credential against its configured method. Only after authentication succeeds does Besu evaluate the request against the permissions files for any account or node action involved. A failure at any step should produce a clear error, so test each step separately with an invalid token, an expired token and an account outside the permissions file.

Choosing between a credentials file, JWT validation and gateway authentication

This table compares three ways to control who can call Besu's JSON-RPC API: a credentials file on each node, JWTs validated against an identity provider's public key, and authentication enforced at a gateway with Besu reachable only from that layer. Read each column for fit and operating cost, then check the rows on signing keys, identity provider outages and revocation before choosing. The main takeaway is that key ownership and identity provider availability usually decide the choice.

Decision factor	Credentials file	JWT validation in Besu	Gateway or proxy enforcement
When it fits	A small, fixed set of operators or service accounts that change rarely	Many users already managed in an identity provider, with per-user tokens	Several node APIs behind one enforced access point, with a team that owns access policy
Who holds signing keys and who rotates them	No signing key. Node operators hold the password file and rotate passwords by hand on each node	The identity provider holds the private signing key. The identity team rotates it and the public key is updated in Besu	The gateway team holds TLS and any token keys. Besu holds no user secrets, so rotation stays at the gateway
Password or secret distribution	Passwords must reach each operator and client securely, and every node file must be updated on change	No shared passwords. Clients obtain tokens from the identity provider on their own schedule	Depends on the gateway's login method. Besu sees only the connection from the gateway
Token lifetime handling	Not applicable. A credential stays valid until the file changes	Expiry is set by the identity provider. Confirm which token claims the Besu version checks	Lifetime is enforced at the gateway, so it only holds if Besu is unreachable from outside
Audit trail gaps	Shared logins hide which person acted. Confirm what Besu logs for each request	Subject claims identify users, but Besu logs may not record them. Confirm before relying on them	The gateway can log identity per request, but Besu logs need correlation to show it
Dependence on a proxy	Besu does not terminate HTTPS, so a TLS-terminating proxy is still needed	Still needs TLS termination in front of Besu, so a proxy or load balancer is required	High. A proxy misconfiguration can expose unauthenticated JSON-RPC, so direct access must be blocked
If the identity provider is unavailable	Unaffected, because no external call is made during login	Validation continues from the locally loaded key, but no new tokens are issued until recovery	New gateway sessions stop. If the gateway checks the provider per request, all node access stops
Revocation	Removing an operator means editing every node's file and confirming the change on each node	A valid token is accepted until it expires, so short lifetimes are the main control	Fast at the gateway, but only if no direct path to Besu exists

Configuring Hyperledger Besu JSON-RPC authentication step by step

This sequence takes a Besu node from open RPC access to authenticated, encrypted and network-restricted access for named callers. Each step ends with a check so the team can confirm the control works before the next one begins.

Inventory RPC methods by caller
List every caller that reaches a node's JSON-RPC port, such as wallets, back-office services, monitoring jobs and operators, and the methods each one needs. Include read-only calls, transaction submission and administrative methods that change node settings, since administrative access carries the most risk. Ask each application owner to confirm their list against their code, then agree it in writing. Done when every caller maps to a named method set and no caller is granted all methods by default.
Decide which node types are exposed
Separate validators from RPC nodes and decide which node types accept authenticated requests at all. Validators are usually kept off the caller path, so the platform team typically exposes dedicated RPC nodes only. Record which interfaces each exposed node serves, HTTP, WebSocket or both, because each interface needs its own controls. Done when a table lists each node, its role, its exposed interfaces and its callers, and the security team has signed it off.
Confirm the identity provider's signing key
Confirm with the identity provider team which algorithm signs access tokens and where the public key can be retrieved. Besu validates externally issued JWTs against a public key using RS256, RS384, RS512, ES256, ES384 or ES512, so the token algorithm must be one of these. Ask whether the tokens carry issuer or audience values the gateway will check, and confirm the token lifetime and the claims that identify the caller. Done when the algorithm and key are recorded and a test token verifies successfully against that key outside the node.
Enable JWT validation on each node
Turn on JSON-RPC authentication on each exposed node, point it at the public key file and select the algorithm confirmed in the previous step. If the team also uses a username and password credentials file, store it outside the source repository, restrict its file permissions and limit it to service accounts that need it. Confirm the option names in the Besu authentication documentation for the release in use, since they can change between releases. Done when a request with a valid token succeeds and a request with an unsigned token is rejected with an authorization error.
Terminate TLS in front of exposed nodes
Place a TLS-terminating proxy or gateway in front of each exposed node and issue its server certificate from the organization's certificate authority. Besu does not terminate HTTPS natively, so this layer carries encryption in transit for every caller. Decide with the security team whether service callers must present client certificates through mutual TLS. Done when a client that trusts the internal CA connects over HTTPS, and a plain HTTP request to the RPC port from outside the proxy fails.
Map identity groups to gateway routes
Translate each identity group from the inventory into gateway rules that define which routes it may call and which methods it may invoke on each route. Keep administrative methods on a separate route limited to a small operator group, and keep the mapping in version control so changes go through review. Confirm with the Besu documentation how much per-method control the node provides itself, and enforce the rest at the gateway. Done when a test identity from each group can call its permitted methods and receives an authorization failure for a method outside its set.
Restrict network paths to the gateway
Configure firewall or security group rules so the RPC and WebSocket ports accept traffic only from the gateway's addresses, and limit peer-to-peer ports to the node's known peers. Keep metrics endpoints on an internal network with access limited to the monitoring system. Validators should accept connections only from the peers and tools they need. Done when a port scan from outside the gateway shows no open RPC port, and a request sent directly to a node from a non-gateway host is refused or times out.

How the authentication design changes by node role and environment

A development node usually runs on one machine that only the build team can reach, so the main concern is keeping the RPC port closed to anyone outside that machine. Besu documents a username and password credentials file for JSON-RPC authentication, which is the simplest option for this role because the developer can create and rotate it without any external service.

Authentication: A credentials file, or no RPC authentication if the interface is bound to localhost only. Confirm the binding and authentication options in the Besu release you run.
TLS termination: Besu does not terminate HTTPS natively, so keep traffic on localhost or place a local reverse proxy in front of the node. Agree the proxy setup with your team.
Credentials file location: Store it on the developer's machine with restricted file permissions, outside any shared repository.
Node key: The local node private key file is not encrypted, so treat it as a secret even on a laptop.

Confirm that the RPC port is not reachable from other hosts and that development credentials are never reused in shared or staging environments.

Protecting keys, tokens and certificates in an identity integration

An identity integration for Besu JSON-RPC is only as strong as the secrets behind it. The cards below cover the node key file, the credentials file, token validation, token lifetimes, the TLS chain at the proxy and the network exposure of the RPC port. Each one is a place where a gap can let an unauthorized caller reach a node, so each needs an owner and a check before go-live.

Node private key file exposure

Besu's documentation states that the local node private key file is not encrypted, so anyone who can read that file on the host can take the node identity. Confirm who has read access to the data directory, whether backups carry the key in clear form, and whether the host's disk encryption and access logging meet your policy. If the key must sit in hardware-backed storage, scope a security module plugin such as the Besu HSM plugin, enabled with the --security-module option, and confirm its support status for your Besu version before committing.

Credentials file handling

Username and password authentication for JSON-RPC relies on a credentials file on the node host. Keep that file out of version control, including configuration repositories and infrastructure templates, and restrict its permissions so that only the account running Besu can read it. Rotate the stored credentials on a defined schedule and after any staff change, and record who holds the values outside the host. Treat this file as a secret, not as configuration.

Token signing algorithm allowlist

Besu validates externally issued JWTs against a configured public key and accepts RS256, RS384, RS512, ES256, ES384 and ES512. Configure the node to expect one algorithm that matches your identity provider, and make sure the gateway or validation path rejects tokens that declare any other algorithm, including none. Confirm the algorithm your provider signs with and test a token signed with an unexpected algorithm to verify that it is refused.

Token lifetime and revocation planning

A JWT that passes validation remains valid until its expiry time, and Besu does not give you a per-token revocation switch. Set short token lifetimes that fit your operator workflows, and decide how you will cut off access early, such as rotating the signing key, removing the user at the identity provider or blocking the caller at the gateway. Document the time between an access removal decision and the moment the last outstanding token stops working.

TLS chain and renewal at the proxy

Besu does not terminate HTTPS natively, so the TLS endpoint belongs to the reverse proxy or gateway in front of the node. Manage the full certificate chain, including intermediates, at that layer and assign an owner for renewal. Test renewal before expiry, confirm the proxy reloads certificates without dropping authenticated sessions, and monitor expiry dates so that an expired certificate does not become the cause of an outage.

RPC port network restriction

Only the gateway should reach the JSON-RPC port. Bind the RPC listener to the interface the gateway uses, and use host firewall rules or network security groups to block all other sources, including other subnets and monitoring hosts that do not need API access. Verify from outside the gateway that the port does not respond. Permissioning of peers and accounts is covered in depth in the security hardening topic, so use this card as the boundary check for the API surface only.

What drives the effort and cost of Besu API authentication

This table lists the factors that change how much work Besu JSON-RPC authentication takes, how each one raises effort, and what keeps it contained. Use it to scope your own work and to see which questions to put to a partner before agreeing a fixed scope.

Driver	Why it raises effort	How to keep it down
Number of identity sources	Each identity provider adds its own token issuer, claims, key rotation and test cases, and each must be mapped to Besu access levels.	Limit the first release to one issuer and add others later. Confirm whether the sources share signing keys before design starts.
Shared or separate signing keys	Separate key sets mean separate public keys to load into Besu, separate rotation schedules and separate validation tests for each issuer.	Use one signing authority where policy allows, and document a single rotation procedure with the public key file path as the only change point.
Node roles exposed (validators, RPC, archive)	Validators rarely need public JSON-RPC access, while RPC and archive nodes do. Each exposed role needs its own endpoint rules, method allow lists and tests.	Keep validators off caller-facing APIs and expose only RPC nodes. Treat archive nodes as a separate scope item if they serve different callers.
Distinct caller groups and permission mapping	Every group needs a documented set of allowed JSON-RPC methods, and mismatches between token claims and intended access are a common source of rework.	Start with a short list of roles, write the claim-to-method matrix before configuring anything, and get sign-off from the data owners for each role.
Environments needing their own keys and certificates	Development, test, pre-production and production each need separate credentials, public keys, TLS certificates and rotation records, multiplying setup and checks.	Automate generation of environment-specific configuration from one template, and keep only production keys in a restricted store.
Reuse of an existing gateway or proxy	Building TLS termination, token checks and rate limits from scratch adds design and testing. Adapting an existing gateway needs its own integration test and sometimes a change request.	Confirm early whether the existing gateway can pass through bearer tokens and enforce per-method rules. Ask the gateway owner for their current policy export.
Compliance evidence and access reviews	Assessors commonly ask for access review records, change logs for role mappings and proof that revoked identities lost access. Producing these on a schedule adds recurring work.	Define the evidence list with your compliance lead at the start, export log formats that the review tool already reads, and schedule reviews on the same cadence as the identity provider's reviews.

How to test that Besu API authentication works and fails safely

Test the authentication layer before any application depends on it, and record an expected result for every case before you run it. Start with the token path. A valid token issued by your identity provider should succeed for a method your caller's group is allowed to use. Then present an expired token, a token signed with a key that Besu does not hold in its configured public key, and a token signed with an algorithm outside the set Besu accepts for JWT validation: RS256, RS384, RS512, ES256, ES384 or ES512. If your identity provider sets an audience claim, also send a token with a wrong audience. Each of these should be rejected. Writing the expected outcome first lets you compare what happened with what you predicted, which is the basis of a defensible test record.

Next, cover the paths that involve no valid token. Send a request with no credentials at all. Then, on a node configured with a credentials file, attempt a login with a valid username and the wrong password. Both should fail. Authorization is a separate control, so test it on its own: use a token that is valid for a caller in a group that must not call a sensitive method, such as one that changes node or account state. The call should be refused even though authentication succeeded. Map each role in your access model to its permitted method groups before you start, and confirm the mapping against the Besu authentication documentation for your release, because configuration options depend on the version you run. Record the error responses you observe and check them against the documented responses for each case.

The most important test goes around the gateway. Besu does not terminate HTTPS natively, so TLS and the identity check sit in front of the node, and that arrangement only holds if nothing else can reach the JSON-RPC port. From a host that can reach the node network but is not meant to use the gateway, send a request with no credentials directly to the node port. It must fail. Then send a direct request with a valid token. If your gateway is where rate limits, request logging and TLS live, a direct valid call skips all of them, so decide in advance whether the node should accept it at all. Repeat the checks for the WebSocket endpoint if you enable it, since it is a separate entry point to the same methods. Confirm the port is not reachable from outside your network segment.

A safe failure has three properties. First, the request is rejected before any method runs, so the caller receives an error and no partial result, with no fields from a response that was being built when the check failed. Second, the rejection creates a logged event that records the time, the source address, the presented identity and a reason category, without storing the token or the password. Third, the node keeps serving legitimate callers. Verify each property in the logs from both the node and the gateway, and confirm which events your Besu version writes instead of assuming the content. For an access review, keep for each test case the request sent with secrets redacted, the timestamp, the response received, the matching log lines, the configuration version and the tester's identity. Store the matrix with the configuration files so an auditor can trace each control to its test result. This evidence supports the review, and the independent assessor draws the conclusion.

What to monitor, rotate, back up and document after go-live

Once callers authenticate, the work shifts to keeping the controls true over time. Monitoring tells you when access is being tested or bypassed, rotation keeps credentials and keys current without outages, and backups and documentation make the setup recoverable and auditable by someone other than the people who built it.

Monitoring authentication events

Besu's metrics, enabled with --metrics-enabled, report node health such as peers, sync and block production. They do not record who authenticated or who was rejected, so authentication logging usually comes from the gateway in front of the node. Confirm that the gateway logs rejected attempts with source address, caller identity and requested method, and that Besu's own logs capture rejected or unexpected RPC requests. Alert on spikes in rejections, not only on single failures.

Detecting direct port access

If callers can reach the node's JSON-RPC port without passing through the gateway, authentication is bypassed regardless of how well the gateway is configured. Check network rules and host firewall settings after every infrastructure change, and watch for connections to the RPC port from addresses other than the gateway. Treat any direct connection as an incident until the source is explained.

Tracking certificate and key expiry

Record the expiry date of every TLS certificate that terminates in front of the node, and of any signing certificate used by the identity provider. An expired certificate causes a hard outage for every caller at once, so schedule alerts well ahead of the expiry date. Confirm with your identity provider how and when it rolls its signing keys and whether it publishes the new key before it stops using the old one.

Rotating the JWT signing key

When the identity provider rolls its signing key, the public key in the Besu configuration must change too. Plan an overlap period in which both the old and new public keys are accepted, so tokens issued before the switch keep working until they expire. Confirm with your Besu version and documentation how multiple keys or a key replacement are handled, and test the sequence in a non-production environment first.

Changing credentials file passwords

The credentials file holds usernames and password hashes for basic authentication. Set a schedule for password changes and a process for removing accounts when a person or service leaves. After each change, confirm that the affected callers reconnect successfully and that the old credentials are rejected. Keep a record of who holds each account so revocation can be completed quickly.

Renewing TLS certificates

Besu does not terminate HTTPS natively, so the TLS certificate and its renewal belong to the component that does, such as the reverse proxy or gateway. Renew before expiry, deploy the new certificate with a configuration reload rather than a restart where possible, and verify the chain from an external client. Confirm the renewal path works for the platform you use, including any automated issuance.

Backing up the credentials and proxy configuration

Store the credentials file, the public key used for JWT validation and the proxy configuration under version control or in a controlled configuration store, and record where each restored copy must be placed. Test a restore in a separate environment so that a failed node or gateway can be rebuilt without re-creating accounts by hand. Confirm file ownership and permissions survive the restore.

Backing up the node private key

The node private key file is not encrypted by Besu, so its backup needs the same protection as other key material, with access restricted to the people who handle node recovery. It belongs in the node backup plan, not the authentication configuration backup, because losing it changes the node identity and can affect peering and validator operation. Confirm where any hardware-backed key storage fits in this plan before go-live.

Documenting the caller-to-method matrix

Maintain a matrix that maps each caller or role to the JSON-RPC methods it may call, and review it whenever a new integration is added. Auditors and new operators need this to confirm that permissions match intent. Keep the matrix tied to the configuration in version control so that a change to one prompts a change to the other.

Recording accepted algorithms

Document the signing algorithms the deployment accepts for JWTs, such as the RS and ES families Besu supports, and the algorithms your identity provider actually issues. Remove any algorithm that is accepted but not in use, and record the reason for each one kept. When the identity provider changes its signing algorithm, this record shows exactly what must be updated on both sides.

Writing revocation runbook steps

Write a runbook for revoking a caller's access, covering the credentials file entry, identity provider sessions and tokens, gateway rules and any cached authorization. Name the owner of each step and the order in which they run, and test the runbook on a non-production account. Revocation is only complete when a test call with the old credentials fails at every layer.

How much does Hyperledger Besu JSON-RPC authentication cost to set up?

How much does it cost to set up Besu JSON-RPC authentication?

No price list exists. The cost follows the written scope. Besu is open source under Apache 2.0, so there is no license fee for the authentication feature itself. The spend is on labor and the systems around it: analysis of which callers need access, configuration of the credentials file or JWT validation, identity provider integration, TLS termination in front of nodes, testing and documentation. The largest drivers are the number of nodes and environments, how many identity sources and caller groups must map to permissions, whether your identity provider can issue tokens that Besu validates, and how much of the work your own team performs. Ask any provider for a quote that lists each deliverable, the environments covered, who performs each task, and which items are one-time and which recur, such as signing key rotation and certificate renewal.

How long does Besu JSON-RPC authentication take to set up?

Timing depends mostly on access and approvals, and the configuration work often moves faster than the waiting around it. Three things set the calendar. Identity provider access comes first, because someone with admin rights must register the client, define claims and export the signing key. Certificate issuance can add delay, since TLS certificates for each node endpoint often pass through an internal certificate authority with its own queue. Change windows matter most for validator and RPC endpoints, because enabling authentication usually needs approval and a planned restart. Ask the provider to show which of these items sits on the critical path and which dependencies the client must clear before work starts. Request a duration estimate only after access, certificate lead times and change windows are confirmed in writing.

What does my team need to provide for an authentication project?

Plan for four inputs before work starts. Identity provider admin access lets the team register the client, configure token claims and confirm the signing algorithm and public key used for validation. A named owner for keys and certificates is one person or role who approves key generation, storage, rotation and certificate renewal, and who answers when tokens stop validating. Network change approval covers firewall rules, reverse proxy or load balancer changes and the maintenance window for restarts. A list of caller groups maps each application, operator and service account to the access it needs, such as read-only queries, transaction submission or administrative methods. Missing any of these usually stalls the project, so confirm each one in the written scope before the schedule is agreed.

Can an in-house team set up Besu authentication without a partner?

Yes, if the team already has working experience with Besu and with the identity provider involved. The work is configuration and integration, so a platform or security engineer who knows both systems can carry it. Use this checklist as the build sequence:

Confirm the Besu version, the JDK in use and the JWT signing algorithms your identity provider can issue.
Decide between a credentials file and JWT validation for each caller group.
Register the client and claims in the identity provider and export the public key.
Configure Besu authentication and test each caller group against a non-production node.
Place TLS termination in front of nodes and verify the certificate chain and renewal process.
Map callers to permissions and confirm that rejected requests are refused.
Document key owners, rotation dates and rollback steps, then promote to production in a change window.

What happens after go-live with Besu authentication?

Authentication needs ongoing ownership, so plan support before go-live. Recurring tasks include rotating signing keys and credentials, renewing TLS certificates, updating caller groups when people or applications change, and reviewing each Besu release for changes that affect its configuration. Your team can own these tasks, or DeployOpen can provide ongoing support or a retainer that covers upgrades and continuous testing. Retainer scope, response expectations and the handling of configuration changes during an upgrade should be written into the agreement before go-live. Ask whether the handover includes runbooks, alert rules for failed authentication attempts and a tested rollback that starts from a backup taken before any database upgrade.

Which JWT signing algorithms does Besu accept from an identity provider?

Besu validates externally issued JWTs against a public key using RS256, RS384, RS512, ES256, ES384 or ES512. Your identity provider must be able to sign tokens with one of those algorithms and expose or export the matching public key. Confirm the algorithm, token claims and key format with your identity provider's vendor before scoping, because the design changes if tokens are signed differently. If the provider cannot issue a supported signature, the scope will need a credentials file for some callers or an intermediary service that issues compatible tokens, which adds cost and a second system to run. Ask the provider to demonstrate a test token validated against a non-production node as part of the proposal.

How DeployOpen works on this

DeployOpen starts by mapping which Besu callers need JSON-RPC access, which identity source they already trust and where TLS will terminate. We then build the authentication layer inside your infrastructure and hand over the configuration, tests and runbooks your team needs to operate it.

How we scope

Inventory every client, service and operator that calls Besu JSON-RPC endpoints and the methods each one needs.
Confirm whether access will use a credentials file, externally issued JWTs validated against a public key, or both.
Agree in writing which identity provider issues tokens, which signing algorithms are in use and who owns key rotation.

How we build

Configure Besu JSON-RPC authentication with the credentials file or JWT public key settings chosen during scoping.
Place TLS termination in front of each node with a reverse proxy or gateway, since Besu does not terminate HTTPS natively.
Map user roles to permitted operations and test that each role can call only the methods it was granted.

How we hand over

Deliver configuration files, proxy settings and permission mappings in your version control, with a record of each design decision.
Provide test evidence showing accepted tokens, rejected tokens, expired tokens and blocked methods on each node.
Document the runbook for rotating public keys, adding users, revoking access and recovering the node key material.

How we support

Fixed-scope engagements have deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer, including review when Besu releases change authentication behavior.
Ask any quote to separate one-time build effort from recurring support, and to state what each retainer covers after go-live.