Security

Flowker protects your workflows, data, and integrations through API Key authentication, per-executor credential management, and HTTPS enforcement. This page covers the security model as implemented in the current release.

Platform authentication

Flowker supports two platform authentication modes, selected by configuration:

API Key — a static key sent in the X-API-Key header, enabled with API_KEY_ENABLED.
Access Manager — token-based authentication, enabled with PLUGIN_AUTH_ENABLED. When both modes are enabled, Access Manager takes priority.

Enable at least one mode in production.

curl -X GET https://your-flowker-instance/v1/workflows \
  -H "X-API-Key: your-api-key"

How it works:

API Key mode — the middleware validates the key on every request; a valid key grants access to all endpoints. Configure the key via environment variables or bootstrap configuration.
Access Manager mode — each request carries a Bearer token, and every route enforces a per-resource, per-action permission. This is how role- and policy-based authorization is applied.
Invalid or missing credentials return 401 Unauthorized.

Health probe exception: Liveness and readiness probes are excluded from authentication. They are designed for infrastructure monitoring (Kubernetes probes, load balancers) and do not expose sensitive data.

Beyond the static API Key, Flowker can delegate authentication and per-resource, per-action authorization to Access Manager. Enable it via configuration; when enabled, requests carry a Bearer token and each route enforces its own resource/action permission.

Executor authentication

When Flowker calls external services through executors, each executor configuration specifies its own authentication method. This means your platform credentials and your provider credentials are managed separately. Supported authentication types:

Type	Description	Use case
`none`	No authentication	Internal services behind a VPN or service mesh
`api_key`	API Key sent as header or query parameter	Third-party APIs with key-based access
`bearer`	Bearer token in the `Authorization` header	Services using static or pre-generated tokens
`basic`	HTTP Basic authentication (username:password)	Legacy systems or internal APIs
`oidc_client_credentials`	OAuth 2.0 client credentials flow	Machine-to-machine integrations with identity providers
`oidc_user`	OAuth 2.0 user token flow	Integrations that act on behalf of a specific user
`oauth2_token_endpoint`	OAuth 2.0 client credentials against a token endpoint (no OIDC discovery)	OAuth2-style providers without OIDC discovery metadata

Authentication credentials are stored in the executor configuration and used automatically when the executor is called during workflow execution.

{
  "name": "fraud-check",
  "description": "Fraud scoring via Tracer",
  "baseUrl": "https://tracer.example.com",
  "endpoints": [
    {
      "name": "analyze",
      "path": "/v1/transactions/analyze",
      "method": "POST",
      "timeout": 30
    }
  ],
  "authentication": {
    "type": "bearer",
    "config": {
      "token": "eyJhbGciOiJSUzI1NiIs..."
    }
  }
}

For OIDC flows (oidc_client_credentials and oidc_user), Flowker handles token acquisition and refresh automatically. You provide the issuer URL, client ID, and client secret in the executor configuration.

Network security

HTTPS enforcement:

All API endpoints require HTTPS in production
Executor calls to external providers use HTTPS
Sensitive data (credentials, request/response payloads) is always transmitted over encrypted channels

CORS configuration: Flowker supports configurable CORS settings:

Allowed origins are configurable per deployment
Credentials are not allowed in cross-origin requests (AllowCredentials is disabled)
Preflight responses are cached for performance

Resilience

Flowker protects against cascading failures from external services using circuit breaker and retry patterns. Circuit breaker: When an executor’s external service fails repeatedly, the circuit breaker opens and stops sending requests — preventing your workflows from hanging on an unresponsive provider.

Transitions through closed → open → half-open states
Thresholds are configured globally (consecutive failures before opening)
The half-open state allows a limited number of test requests before fully closing

Retries: Failed executor calls are retried with exponential backoff:

Fixed retry count of 5 attempts with exponential backoff (1s, 2s, 4s, 8s)
Exponential backoff between attempts
Only transient failures trigger retries (network errors, 5xx responses)

Audit trail

Every action in Flowker is recorded in the audit log — workflow changes, execution events, executor calls, and configuration updates. This provides a complete chain of evidence for compliance and operational visibility.

Audit events are queryable via the /v1/audit-events endpoint with filters for event type, action, result, resource, and date range
Every entry includes a cryptographic hash linking it to the previous entry, forming a tamper-evident chain
Hash chain integrity is verifiable via the /v1/audit-events/{id}/verify endpoint
Logs include timestamps, actor identification (with IP address), action type, and affected resources

For details on querying audit data, see the Audit events API reference.

What’s next

Integration guide

Learn how to configure executors and connect external services.

Observability

Monitor Flowker with traces, metrics, and structured logs.

Overview

Guides

Console

Operations

Platform authentication

Executor authentication

Network security

Resilience

Audit trail

What’s next

Integration guide

Observability

​Platform authentication

​Executor authentication

​Network security

​Resilience

​Audit trail

​What’s next

Integration guide

Observability

Platform authentication

Executor authentication

Network security

Resilience

Audit trail

What’s next