Secure Third-Party Credentials

Hello! Welcome to the next lesson in our journey to master n8n.

In our last session, we explored the Code node, your escape hatch for writing custom JavaScript. We saw how it can be used for everything from complex data transformations to making custom API calls. However, to interact with most APIs in the real world, you need to authenticate securely. That's precisely our focus today.

This lesson addresses the learning outcome: Set up credentials securely for third-party services. We will explore why hardcoding API keys is a critical mistake and how to use n8n's built-in, encrypted credential store to manage different authentication types safely. As a developer, the principles of secret management will be familiar, and you'll see how n8n implements them in a user-friendly and robust way.

1. The Core Principle: Never Hardcode Credentials

Before we touch the n8n interface, let's establish the foundational rule of API integration: never embed secrets like API keys, tokens, or passwords directly into your code or workflow nodes.

Hardcoding credentials creates significant security risks:

• Accidental Exposure: If you export your workflow to share it or commit it to a Git repository, the secret is exposed in plain text within the workflow's JSON definition.
• Difficult to Rotate: If a key is compromised and needs to be changed, you would have to find and update every single workflow that uses it.
• Poor Access Control: Anyone who can view the workflow can see the secret.

n8n solves this with a centralized and encrypted credential store. Let's start with a high-level overview of why this is so important.

As the article mentions, n8n encrypts your credentials using an N8N_ENCRYPTION_KEY. This is an environment variable that you'll become very familiar with when you set up your own self-hosted instance later in the course. For now, it's enough to know that your secrets are not stored in plain text.

You can find the credential manager in your n8n instance on the left-hand panel. This is your central hub for all authentications.

2. The Wrong Way vs. The Right Way: API Keys & Bearer Tokens

The most common authentication method is a simple API key or a Bearer Token, which are sent in the request headers. Let's see a practical demonstration of what not to do, and then how to do it correctly.

The following video shows a user trying to authenticate with an API. It vividly illustrates the security risk of placing a key directly in an HTTP Request node and then demonstrates the secure alternative using n8n's credential store.

To summarize the correct process for a Bearer Token:

1. Navigate to Credentials and click Add credential.
2. Search for and select Header Auth under "Generic Credential Types".
3. Give your credential a descriptive name (e.g., "OpenAI API Key").
4. For the Name, enter Authorization.
5. For the Value, enter Bearer followed by your API key (note the space after "Bearer").
6. Click Save.

Now, in any HTTP Request node, you can select this credential from the Authentication dropdown menu, and n8n will handle adding the secure header for you.

3. Handling Complex Authentication: OAuth2

Many modern services, especially large platforms like Google, Microsoft, and Salesforce, use OAuth2 for authentication. This flow is more complex than a simple API key because it involves user consent and token exchanges. Instead of you handling a static key, n8n securely stores a client ID and client secret, then manages the process of obtaining and refreshing access tokens on your behalf.

The setup process involves two main parts:

1. On the Service Provider's side: You register your "application" (in this case, n8n) to get a Client ID and a Client Secret. You also need to tell the provider where to redirect the user after they grant permission, which is a specific URL provided by n8n.
2. On n8n's side: You create a credential for that service and provide the Client ID and Secret you just obtained.

The official n8n channel has a fantastic video walking through this entire process for Google services.

While the specific steps vary between services, this general pattern of registering your application, getting a Client ID/Secret, and providing a redirect URI is the standard for OAuth2.

4. Best Practices for Production-Grade Security

Creating a credential is just the first step. To build robust and secure automations, especially in a professional context, you should follow established best practices for secret management. Given your background, these will align with standard software development security principles.

The following resource provides a concise, actionable list of these practices.

Let's consolidate the most important best practices:

• Principle of Least Privilege: When you create an API key or authorize an OAuth2 connection, grant it only the permissions it absolutely needs. If a workflow only needs to read data, create a read-only key.
• Separate Credentials by Environment: Avoid using the same API keys for your development, staging, and production environments. This prevents accidental changes to production data while you are testing.
• Use Clear Naming Conventions: Don't use generic names like "My Google Key". A name like Prod - Google Sheets - Marketing Dept (Read/Write) is far more useful and helps prevent mistakes.
• Regularly Rotate Credentials: Schedule periodic rotations of your API keys (e.g., every 90 days). If you ever suspect a key has been compromised, rotate it immediately.
• Audit and Revoke: Periodically review which credentials are being used and revoke any that are no longer needed.

Conclusion

In this lesson, you've learned the essential skill of managing credentials securely in n8n. This is a non-negotiable part of building any serious automation that interacts with external services.

Key Takeaways:

• Always use the n8n credential store. Never hardcode secrets like API keys or tokens in your workflow nodes.
• n8n provides Generic Credential Types like Header Auth to handle common authentication methods for any API.
• For complex standards like OAuth2, you'll perform a two-part setup: one on the service provider's platform and one inside n8n.
• Adopting security best practices—like the principle of least privilege, clear naming, and regular rotation—is crucial for building professional, production-ready workflows.

Now that we know how to securely store the "keys" to our services, we're ready to unlock their potential. In the next lesson, we will connect to services using pre-built integration nodes, putting the credentials you've learned to create today into direct, practical use.