DEV Community

Nick
Nick

Posted on

Part 9: Security First - Credentials, Auth, and Secrets Management

#dotnet #csharp #security #architecture

Building a workflow engine that interacts with external APIs, databases, and internal systems means you are constantly handling sensitive data. If you get security wrong here, the consequences are severe. Today, we are discussing how we handle credentials, authentication, and secrets management in Vyshyvanka.

The Problem: Where do secrets live?

The biggest mistake developers make when building automation tools is hard-coding credentials. Whether it is an API key in a config file or a database password in an environment variable, these secrets eventually leak. We needed a way to manage secrets that is both developer-friendly and secure enough for production environments.

The Credential Store

In Vyshyvanka, we do not store raw secrets in the workflow definition. Instead, we use a dedicated Credential Store. When you add a new service integration to your workflow, you create a Credential object through the Credential Manager UI. This object holds the encrypted access data for that service.

Each node that needs authentication is assigned a CredentialId in its configuration. At runtime, the engine resolves that reference through the ICredentialProvider, decrypts the credential in-memory, and provides it to the node instance. The raw secrets never appear in workflow JSON, API responses, or execution logs.

// How a node receives its credential at execution time
var input = new NodeInput
{
    Data = inputData,
    Configuration = evaluatedConfig,
    CredentialId = node.CredentialId  // Reference, not the actual secret
};
Enter fullscreen mode Exit fullscreen mode

Three Storage Backends

We support three credential storage providers, configurable via appsettings.json:

Provider Config Value How Secrets Are Stored
Built-in BuiltIn AES-256 encrypted in the database
HashiCorp Vault HashiCorpVault Vault KV v2 secret engine
OpenBao OpenBao OpenBao KV v2 secret engine

All three share the same ICredentialService interface and CredentialValidator logic. The choice of backend is transparent to the rest of the system — nodes never know where their credentials are stored.

Encryption at Rest (Built-in Provider)

For the built-in provider, we use AesCredentialEncryption with AES-256. The master encryption key is managed via environment variables — never stored in appsettings.json or committed to source control.

public sealed class AesCredentialEncryption : ICredentialEncryption
{
    // Encrypts credential data before DB persistence
    // Decrypts on-demand when a node needs access
}
Enter fullscreen mode Exit fullscreen mode

Even if a database backup is compromised, the actual credentials remain encrypted and unusable without the master key.

External Secrets Managers (Vault / OpenBao)

For enterprises that already manage secrets centrally, the VaultCredentialService delegates all secret storage to HashiCorp Vault or OpenBao. Metadata (name, type, associations) stays in the database, but the actual sensitive values live in the vault's KV v2 engine.

This gives you:

  • Centralized secret rotation without touching Vyshyvanka
  • Audit trails from the vault itself
  • Integration with existing enterprise key management

Authentication Providers

Vyshyvanka supports four authentication strategies, selectable at deployment time:

Provider Session Tokens Login Flow
Built-in Local JWT Username/password via API
Keycloak External OIDC Redirect to Keycloak
Authentik External OIDC Redirect to Authentik
LDAP Local JWT Verify against directory

For OIDC providers, the API validates external tokens and an OidcClaimsTransformation middleware provisions local users on first login. For LDAP, the LdapAuthenticationService verifies credentials against the directory server.

Additionally, API key authentication (X-API-Key header) is always available regardless of the primary provider — useful for CI/CD integrations and automated workflow triggers.

Node-Level Auth Strategies

Our node architecture supports various authentication strategies per credential type:

  • Basic Auth: Username/password for legacy services
  • Bearer Tokens: The standard for most modern REST APIs
  • API Keys: Header or query parameter based
  • Custom Headers: For services with non-standard auth schemes

Each node that requires credentials declares this with the [RequiresCredential] attribute, and the Designer UI automatically shows the credential picker for that node.

Security Rules We Enforce

Always:

  • Encrypt credentials at rest (AES-256 or delegate to Vault/OpenBao)
  • Validate resource ownership via ICurrentUserService before any operation
  • Use parameterized queries for all database operations
  • Sanitize user input in expressions to prevent injection

Never:

  • Return credential values in any API response
  • Log credentials or sensitive data at any log level
  • Allow cross-user workflow access without explicit sharing
  • Store Vault/OpenBao tokens in plain text in config files

Best Practices

  • Rotate your keys: The credential store allows you to update a secret without modifying workflow logic. The CredentialId reference stays the same.
  • Use scoped permissions: If a service supports it, create API keys with minimum required permissions.
  • Choose the right backend: Use Vault/OpenBao for production environments where compliance and audit trails matter. The built-in provider works well for development and small deployments.

Security is not a feature you add at the end; it is the foundation on which everything else is built.

In the next part, we will discuss Part 10: Plugin System Architecture - Extensibility by Design. Stay tuned!

Check out the project source code here: https://github.com/homolibere/Vyshyvanka

Top comments (0)