6 min read

Overview

Want to build an add-on but not sure how to manage user access? QuickNode now supports three authentication methods, each designed for different use cases and security requirements. Whether you're building an open public service, need simple access control, or require complex user management, there's an authentication option that fits your needs.

This guide explores the different authentication methods available for QuickNode Marketplace add-ons, traditional Provisioning APIs, HTTP Basic Auth, and No Authentication. This guide explores each method, helping you choose the best approach for your service based on your specific requirements.

What You Will Learn

• The different authentication methods available for QuickNode Marketplace add-ons
• The benefits and trade-offs of each method
• Implementation examples for each authentication method

What You Will Need

• A QuickNode partner account
• Familiarity with HTTP requests and responses
• Basic understanding of API concepts and Web3 development

QuickNode Partner Account

If you don't have a QuickNode partner account yet, it's easy to get started. After logging in to your QuickNode dashboard, click on the avatar icon on the top left and select the Switch to Partners tab, and then complete the marketplace account application. Approval process for new marketplace partners may take up to 7 business days, however, in general, you can generally expect a response in 1-2 business days.

Ready to Build?

This guide focuses on authentication, but QuickNode offers extensive resources for building add-ons from scratch. Check out the following resources:

• 10-week Marketplace Course
• Marketplace Partner Guides

Starter Code repositories:

• Starter Code - Python
• Starter Code - JavaScript
• Starter Code - Ruby
• Starter Code - Go
• Starter Code - Ruby on Rails

Authentication Methods

Before diving into the details of each method, here's a quick overview of the three authentication options available for QuickNode marketplace add-ons:

Authentication Method	Best For	Security Level	Implementation Complexity	User Management
Provisioning APIs	Usage tracking, granular user management	High	Medium	Full control per user
HTTP Basic Auth	Private services with simple access control	Medium	Low	Service-level only
No Authentication	Open services, public APIs, community tools	None	None	Not applicable

Note: QuickNode handles rate limiting for all authentication methods, so you don't need to implement your own rate limiting logic.

Provisioning APIs

Traditional provisioning APIs provide maximum flexibility and control over user management, usage tracking, and access control. This method requires implementing custom endpoints for user lifecycle management. With this approach, QuickNode interacts with a set of APIs you provide to automate the lifecycle of user subscriptions.

Required Endpoints

You need to implement these key endpoints for provisioning APIs:

Endpoint	Description
/provision	Creates a new instance of your add-on for a QuickNode user
/deprovision	Removes an add-on instance when a user unsubscribes
/deactivate_endpoint	Deactivates a specific endpoint associated with your add-on
/update	Updates an existing provisioned add-on instance

Security Requirement: You must protect your provisioning APIs with HTTP Basic Auth. QuickNode provides the username and password during add-on setup.

Learn more about how provisioning works for Marketplace Partners in our dedicated guide: How Provisioning Works for Marketplace Partners.

Implementation Example

QuickNode provides starter code in various programming languages to help you get started. Here's an example from our Node.js starter code:

This example demonstrates the /provision endpoint from a QuickNode Marketplace add-on starter template. It handles the creation of new accounts and endpoints when a user subscribes to your add-on. The basicAuth(authInfo) middleware protects this endpoint with HTTP Basic Auth.

Code snippet for a provisioning API

router.post('/provision', basicAuth(authInfo), async (request, response) => {
	const [account, accountCreated] = await models.Account.findOrCreate({
		where: { quicknode_id: request.body['quicknode-id'] },
		defaults: {
			is_test: request.headers['X-QN-TESTING'] === 'true',
			plan: request.body['plan'],
		},
	})
	console.log('Upserted account with id: ' + account.get('id'))

	const [endpoint, endpointCreated] = await models.Endpoint.findOrCreate({
		where: {
			quicknode_id: request.body['endpoint-id'],
			account_id: account.get('id'),
		},
		defaults: {
			is_test: request.headers['X-QN-TESTING'] === 'true',
			plan: request.body['plan'],
			chain: request.body['chain'],
			network: request.body['network'],
			wss_url: request.body['wss-url'],
			http_url: request.body['http-url'],
		},
	})
	console.log('Upserted endpoint with id: ' + endpoint.get('id'))

	var baseUrl = request.protocol + '://' + request.get('host')

	response.json({
		status: 'success',
		// replace below with real URL for sso login
		'dashboard-url': `${baseUrl}/dashboard`,
		'access-url': `${baseUrl}/api`, // Return null if not applicable
	})
})

HTTP Basic Auth Protection

HTTP Basic Auth provides a lightweight and secure way to protect your Marketplace add-on endpoints without the need for custom provisioning APIs. When you select this option, QuickNode includes a standard HTTP Basic Auth header in every request forwarded to your add-on's service endpoint.

If you select HTTP Basic Auth protection, requests forwarded to your service endpoint will include a Basic Auth HTTP Header. This header is in the format Authorization: Basic <credentials>, where <credentials> is the Base64 encoding of a username and password joined by a single colon (e.g., username:password). Your add-on service is responsible for validating these credentials with each incoming request.

QuickNode securely stores the username and password you provide during the add-on setup and automatically generates the Base64 encoded string for inclusion in the Authorization header.

Example of an Authorization header, where Aladdin is the username and open sesame is the password:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Implementation Example

Here's a simple example of how to implement HTTP Basic Auth in your add-on service using Express.js:

Example of HTTP Basic Auth header

import { Router } from 'express'
const basicAuth = require('express-basic-auth')
const router = Router()

// Provisioning API is behind basic auth
const authDetails = {}
authDetails[process.env.BASIC_AUTH_USERNAME] = process.env.BASIC_AUTH_PASSWORD
const authInfo = {
	users: authDetails,
	challenge: true,
	unauthorizedResponse: 'Not Authorized',
}

// Apply the basicAuth middleware to your RPC endpoint.
// Any request to '/rpc' will first be authenticated using the provided credentials.
router.post('/rpc', basicAuth(authInfo), async (request, response) => {
    // Process the authenticated request
	const { method, params } = req.body

	// Your service logic here
	const result = processRequest(method, params)

    response.json({
        jsonrpc: '2.0',
        result: result,
        id: request.body.id
    })
})

No Authentication

No authentication is perfect for open services that don't require access control or user verification. This option provides the simplest integration path with minimal overhead.

Requests from QuickNode are forwarded directly to your service endpoint without any authentication headers or credentials. Your service receives the raw requests exactly as they come from users.

Implementation Example

Your service simply needs to handle incoming requests without authentication checks:

Example of No Authentication

import { Router } from 'express'
const router = Router()

router.post('/rpc', async (request, response) => {
    // Process the request directly - no auth needed
    const { method, params } = request.body
    
    // Your service logic here
    const result = processRequest(method, params)
    
    response.json({
        jsonrpc: '2.0',
        result: result,
        id: request.body.id
    })
})

Choosing the Right Method

Select your authentication method based on these key considerations:

Choose Provisioning APIs when you need:

• Granular access control and user management
• Custom dashboard or user interface
• Complex business logic tied to subscriptions

Choose HTTP Basic Auth when you need:

• Simple access control for private services
• Security without complexity
• Service-level authentication (not per-user)
• Quick implementation with minimal overhead

Choose No Authentication when you're building:

• Open public services or APIs
• Community tools and utilities
• Services that benefit from unrestricted access
• Simple integrations requiring maximum performance

Conclusion

QuickNode's flexible authentication options make it easier than ever to integrate your services with the marketplace. HTTP Basic Auth provides the sweet spot for most private services, offering security without complexity. No authentication enables open services to integrate seamlessly, while traditional provisioning APIs continue to support advanced use cases requiring custom user management.

Ready to build your QuickNode marketplace add-on? Check out the resources below to get started. If you have any questions, feel free to use our dedicated channel on Discord or provide feedback using the form below. Stay up to date with the latest by following us on X and our Telegram announcement channel.

We ❤️ Feedback!

Let us know if you have any feedback or requests for new topics. We'd love to hear from you.

Further Resources

• 10 Week-length Marketplace Course: Building a JSON-RPC Add-On for Marketplace
• Marketplace Partners Page: QuickNode Marketplace Partners
• Marketplace Partners Guides: QuickNode Marketplace Guides