API Authentication
Nected provides comprehensive authentication and authorization capabilities to ensure the absolute safety of your data and secure API interactions. This guide covers how to securely connect external APIs with Nected, as well as how to use Nected's APIs within your own external systems.
Overview
Nected's authorization system supports two primary use cases:
Connecting External APIs to Nected: Use authentication configurations to securely authenticate when calling external or internal APIs from Nected. Nected automatically manages token fetching, caching, and refresh for authenticated API integrations.
Using Nected APIs in External Systems: Use Nected-generated API keys to securely access Nected Rule APIs from your external applications. These keys are used when Rule APIs are marked as Private.
All authorization settings are managed from the Authorization tab, accessible through the SECURITY section in the Nected navigation.
Authentication Configuration
When you need to call an authenticated API (internal or third-party) from Nected, you can create an authentication configuration that will automatically authenticate the endpoint when it is called. Nected handles the complexity of token management for you.
How It Works
Automatic Authentication: When an API is executed in Nected, the execution environment automatically checks for valid, non-expired tokens in cache before making the request.
Token Refresh: If tokens are expired or missing, Nected automatically fetches new tokens and refreshes them as needed.
Token Caching: Nected manages token caching to optimize performance and reduce unnecessary authentication requests.
Creating a New Authentication Configuration
To create a new authentication configuration:
Navigate to the Authorization tab (under SECURITY in the navigation)
Click the + New Authentication button in the Authorization section
Select one of the four available authentication types from the dropdown menu:
Bearer Token | API Key | Basic Auth | OAuth 2
Once you've selected an authentication type, a configuration modal will open where you can enter the required credentials and settings for that specific authentication method.
Authentication Types
Nected supports four types of authentication configurations, each designed for different use cases and security requirements.
1. Bearer Token
Bearer Token authentication is a simple and widely-used method for HTTP authentication. It uses a private authentication key (token) that is sent with each API request.
How It Works: When you use a Bearer Token integration, Nected automatically appends the token value to the word "Bearer" in the Authorization header of each request in the following format:
Configuration Fields:
Header: The header name where the bearer token will be sent (default: "Authorization")
Token: Your private authentication key/token value
Use Case: Ideal for APIs that use simple token-based authentication. Commonly used with REST APIs that require a token in the Authorization header.
2. API Key
API Key authentication allows you to send a key-value pair to the API either in the request headers or as query parameters. This method uses a code to identify the calling program and ensure it has permission to access the API.
How It Works: When you use an API Key integration, Nected appends the key-value pair to your request headers or URL query string, depending on your configuration.
Configuration Fields:
Key: The header name or query parameter name that will be used (e.g., "X-API-Key", "api_key")
Value: Your API key value
Use Case: Perfect for APIs that require an API key for identification and authorization. Can be sent either as a custom header or as a URL query parameter.
3. Basic Auth
Basic Auth is a standard HTTP authentication method that uses a username and password combination. It provides a simple way to authenticate API requests using credentials.
How It Works: When you use Basic Auth, Nected automatically encodes your username and password using Base64 encoding and sends them in the Authorization header as:
Configuration Fields:
Username: The username for authentication
Password: The password for authentication (with visibility toggle for security)
Use Case: Suitable for APIs that require username and password authentication. Commonly used with legacy systems or APIs that haven't implemented more advanced authentication methods.
4. OAuth 2.0
OAuth 2.0 is a widely-adopted, open-standard authorization protocol that enables secure, delegated access to user accounts and resources. It provides the most secure method for third-party application integrations.
OAuth 2.0 uses a token-based flow where Nected exchanges credentials or authorization codes for access tokens that are used to authenticate API requests. The protocol eliminates the need to share password credentials directly.
Grant Types Supported:
Client Credentials: Ideal for server-to-server authentication where the client is also the resource owner
Password Grant: Suitable when user credentials are available to the client application
Authorization Code: The most secure grant type, commonly used for web applications requiring user consent
Configuration Fields (vary by grant type):
Grant Type: Select the appropriate OAuth 2.0 grant type
Authorization URL: Endpoint for user authorization (Authorization Code grant)
Token URL: Endpoint for obtaining access tokens
Client ID: Unique identifier for your application
Client Secret: Confidential key for your application
Header Prefix (optional): Prefix for the authorization header (e.g., "Bearer")
Audience (optional): Intended recipient of the token
Scope (optional): Comma-separated list of permissions requested
Use Case: Essential for integrating with third-party services that require OAuth 2.0 authentication. Provides the highest level of security for external API integrations.
For detailed step-by-step instructions on setting up OAuth 2.0, including prerequisites, grant type details, and integration workflows, refer to the OAuth 2.0 detailed documentation.
Authentication Keys (Nected API Keys)
Authentication Keys are Nected-generated API keys used to secure API calls to trigger Nected Rules from your external systems. These keys allow you to authenticate when calling Nected Rule APIs that have been marked as Private.
When you need to trigger Nected Rules from external applications or systems, you can use these authentication keys to securely authenticate your requests. This ensures that only authorized applications can trigger your private Rule APIs.
How to Use Nected API Keys
Mark Rule API as Private: First, configure your Rule API to be Private. Refer to the Triggering a Rule using an API documentation for details on how to configure and secure Rule APIs.
Copy the Secret Key: From the API Keys section, copy the secret key value for the authentication key you want to use.
Include in API Requests: When making requests to your Private Rule API, include the authentication key in the request header. The exact header name and format may vary based on your Rule API configuration.
Environment Handling: Authentication keys are common across all environments (staging, production, etc.), though you can use different authentication methods for different environments if needed.
Managing Existing Authentications
View All: All your authentication configurations are listed in the Authorization section with their names and types
Update: Click the Update link next to any authentication to modify its configuration
Delete: Use the ellipsis menu (⋮) to access delete options for any authentication configuration
Choosing the Right Authentication Method
Each authentication type serves different purposes and security requirements. Use this guide to choose the appropriate method:
Bearer Token
Simple token-based APIs, JWT tokens
Medium
Low
API Key
Services with custom API key requirements
Medium
Low
Basic Auth
Legacy systems, simple username/password
Low-Medium
Low
OAuth 2.0
Third-party integrations, modern APIs
High
Medium-High
Security Considerations
Bearer Token & API Key: Simple to implement but tokens should be kept secure. Use HTTPS for all communications.
Basic Auth: Less secure as credentials are transmitted (though encoded). Only use for trusted connections or legacy systems.
OAuth 2.0: Most secure option, especially Authorization Code grant. Provides token refresh capabilities and doesn't expose user credentials.
When to Use Each Type
Use Bearer Token when: Your API uses standard bearer token authentication and you have a token available
Use API Key when: Your API requires an API key in headers or query parameters
Use Basic Auth when: You need to connect to legacy systems or APIs that only support Basic Authentication
Use OAuth 2.0 when: Integrating with modern third-party services, you need high security, or the API requires OAuth 2.0
Related Documentation
Connect REST API to Nected: Learn how to connect a REST API to Nected and use it to trigger Rules and Workflows
Triggering Rules via API: Learn how to configure and secure Rule APIs for external triggering
Triggering Rules via Webhook: Learn how to configure and secure Rule Webhooks for external triggering
Triggering Workflows via API: Learn how to configure and secure Workflow APIs for external triggering
Triggering Workflows via Webhook: Learn how to configure and secure Workflow Webhooks for external triggering
Last updated