INFURA Ethereum Authentication: API Keys & Security (2026)

Authentication overview

INFURA Ethereum provides developers with access to the Ethereum blockchain without requiring them to run their own nodes. Secure access to INFURA's services is managed through authentication, which verifies the identity of the requesting application or user. The primary method for authenticating requests to INFURA Ethereum involves the use of API keys, specifically a Project ID and, optionally, a Project Secret.

These credentials enable INFURA to identify the source of each request, enforce rate limits based on the user's plan (such as the INFURA Core plan offering 100,000 requests/day), and apply security measures like IP address or referrer whitelisting. Proper management and protection of these API keys are critical for maintaining the security and integrity of decentralized applications (dApps) and services built on Ethereum.

Supported authentication methods

INFURA Ethereum primarily relies on API key-based authentication for securing access to its blockchain node infrastructure. This method is straightforward and widely adopted for server-to-server or application-to-service communication. The specific components of INFURA's API key system are the Project ID and the Project Secret.

INFURA recommends using HTTPS for all API requests to ensure encrypted communication, protecting credentials and data in transit. For real-time updates and interactive applications, WebSockets are also supported, where authentication is typically established during the initial connection handshake.

The following table outlines the authentication methods available for INFURA Ethereum:

While INFURA's core authentication is API key-based, developers might integrate additional authentication flows within their dApps for user identity verification, often leveraging Web3 wallets or sign-in with Ethereum (SIWE) mechanisms. However, these are distinct from authenticating with the INFURA service itself, which focuses on authorizing the application's access to the blockchain data.

Getting your credentials

To obtain authentication credentials for INFURA Ethereum, developers must create an account and set up a new project within the INFURA dashboard. Follow these steps to generate your Project ID and Project Secret:

1. Create an INFURA Account: Navigate to the INFURA homepage and sign up for a new account. A free Core plan is available, offering enough requests for initial development.
2. Create a New Project: Once logged into the INFURA dashboard, click "Create New Project." Select "Ethereum" as the network. Provide a descriptive name for your project.
3. Retrieve Project ID: Upon project creation, INFURA automatically generates a unique Project ID. This ID will be visible in your project's settings page within the dashboard. The Project ID is used to construct your API endpoint URL.
4. Generate Project Secret (Optional but Recommended): For enhanced security, especially for backend or sensitive applications, INFURA allows you to generate a Project Secret. Within your project settings, locate the "Security" section and generate a Project Secret. This secret should be treated as highly confidential, similar to a password.
5. Configure Security Settings: In the project settings, configure additional security measures such as IP address whitelisting or referrer whitelisting. These settings specify which IP addresses or web domains are permitted to use your API key, significantly reducing the risk of unauthorized access.

Once generated, your Project ID will be part of the endpoint URL provided by INFURA (e.g., https://mainnet.infura.io/v3/YOUR_PROJECT_ID). The Project Secret, if used, is typically passed via HTTP Basic Authentication headers.

Authenticated request example

Authenticating with INFURA Ethereum depends on whether you are using only the Project ID or both the Project ID and Project Secret. Below are examples for both scenarios using cURL and JavaScript with Web3.js, a popular library for interacting with the Ethereum blockchain.

Using Project ID in the URL (for public dApps/client-side)

When only the Project ID is used, it is directly embedded in the API endpoint URL. This method is common for client-side applications where the Project Secret cannot be securely stored. Ensure referrer whitelisting is configured in your INFURA project settings.

cURL Example (HTTPS)

curl -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest", false],"id":1}' \
  https://mainnet.infura.io/v3/YOUR_PROJECT_ID

JavaScript (Web3.js) Example

const Web3 = require('web3');
const projectID = 'YOUR_PROJECT_ID';
const infuraUrl = `https://mainnet.infura.io/v3/${projectID}`;

const web3 = new Web3(infuraUrl);

web3.eth.getBlockNumber()
  .then(blockNumber => {
    console.log('Current block number:', blockNumber);
  })
  .catch(error => {
    console.error('Error fetching block number:', error);
  });

Using Project ID and Project Secret (for backend services)

For server-side applications, it is best practice to use both the Project ID and a Project Secret via HTTP Basic Authentication. This provides a stronger layer of security as the secret is not exposed in the URL.

cURL Example (HTTP Basic Authentication)

curl -X POST \
  -H "Content-Type: application/json" \
  -u "YOUR_PROJECT_ID:YOUR_PROJECT_SECRET" \
  --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}' \
  https://mainnet.infura.io/v3/

Note that for Basic Authentication, the Project ID is sent as the username and the Project Secret as the password. The endpoint URL in this case does not contain the Project ID.

JavaScript (Web3.js) Example with Basic Auth

When using Web3.js with a Project Secret, you can configure the provider to include authorization headers. Note that direct Web3.js instantiation with basic auth sometimes requires a more custom HTTP provider or a library wrapper, as the standard HttpProvider might not directly expose basic auth parameters in older versions. For newer environments, or when using a custom fetch wrapper, you can achieve this:

const Web3 = require('web3');
const projectID = 'YOUR_PROJECT_ID';
const projectSecret = 'YOUR_PROJECT_SECRET';

// Base64 encode the credentials for Basic Auth
const auth = Buffer.from(`${projectID}:${projectSecret}`).toString('base64');

const infuraUrl = 'https://mainnet.infura.io/v3/'; // No Project ID in URL for Basic Auth

const web3 = new Web3(new Web3.providers.HttpProvider(infuraUrl, {
  headers: {
    Authorization: `Basic ${auth}`
  }
}));

web3.eth.getGasPrice()
  .then(gasPrice => {
    console.log('Current gas price:', web3.utils.fromWei(gasPrice, 'gwei'), 'Gwei');
  })
  .catch(error => {
    console.error('Error fetching gas price:', error);
  });

WebSockets Authentication

For WebSocket connections, authentication typically occurs during the connection establishment. The Project ID is included in the WebSocket URL.

const Web3 = require('web3');
const projectID = 'YOUR_PROJECT_ID';
const infuraWsUrl = `wss://mainnet.infura.io/ws/v3/${projectID}`;

const web3Ws = new Web3(new Web3.providers.WebsocketProvider(infuraWsUrl));

web3Ws.eth.subscribe('newBlockHeaders', (error, blockHeader) => {
  if (!error) {
    console.log('New Block Header:', blockHeader.number);
    return;
  }
  console.error('WebSocket subscription error:', error);
})
.on("connected", function(subscriptionId){
    console.log('WebSocket connected. Subscription ID:', subscriptionId);
})
.on("error", console.error);

Security best practices

Adhering to security best practices is crucial when authenticating with INFURA Ethereum to protect your dApps and user data from unauthorized access or malicious activity. The following recommendations are in line with general API security principles, as outlined by organizations such as the Internet Engineering Task Force (IETF) on API security:

• Protect your Project Secret: If you generate a Project Secret, treat it with the same level of confidentiality as a password. Never hardcode it directly into client-side code, commit it to version control (e.g., Git), or expose it in public repositories. Use environment variables or secure configuration management systems for server-side applications.
• Use IP Address Whitelisting: For backend services that have static outgoing IP addresses, enable IP address whitelisting in your INFURA project settings. This restricts API access exclusively to a predefined list of trusted IP addresses, preventing unauthorized requests from unknown sources.
• Use Referrer Whitelisting: For web-based dApps running in a browser, configure referrer whitelisting. This ensures that API requests originating from domains not specified in your whitelist are rejected.
• Use HTTPS and WSS: Always use encrypted communication protocols (HTTPS for HTTP requests and WSS for WebSocket connections) to prevent eavesdropping and tampering with your API requests and responses. INFURA APIs are accessible over these secure protocols.
• Rotate API Keys Periodically: Regularly rotate your Project IDs and Project Secrets, especially if there's any suspicion of compromise. INFURA's dashboard allows for easy key regeneration, which invalidates old credentials.
• Monitor Usage: Regularly check your INFURA dashboard for unusual activity or spikes in API requests, which could indicate unauthorized use of your credentials.
• Least Privilege Principle: Only grant the necessary permissions to your API keys. While INFURA keys generally provide read access to blockchain data, limiting which chains or methods a key can access, if such granular controls are implemented, can reduce exposure.
• Secure Client-Side Implementations: For client-side dApps where Project IDs are exposed, rely heavily on IP address and referrer whitelisting. Consider using backend proxies to abstract direct INFURA calls if sensitive operations or stricter access controls are needed.