Skip to main content
Flowker protects your workflows, data, and integrations through Access Manager authentication and per-connection credential management. Your deployment manages TLS for API traffic. This page covers the security model as implemented in the current release.

​
Platform authentication

Flowker delegates platform authentication to Access Manager, enabled with PLUGIN_AUTH_ENABLED. When enabled, every request to a protected API route must carry a Bearer token (OIDC JWT), and each protected route enforces a per-resource, per-action permission. This is how role- and policy-based authorization works. Enable Access Manager in production.
How it works:
  • Access Manager enabled: each request to a protected API route carries a Bearer token, and every protected route enforces a per-resource, per-action permission.
  • Access Manager disabled: endpoints do not require authentication. When a Bearer token is present, Flowker still reads the identity from it on a best-effort basis. Flowker attributes the request to the claimed subject. Use this mode only for local development.
  • Invalid or missing credentials return 401 Unauthorized.
Health probe exception: Liveness and readiness probes do not require authentication. They serve infrastructure monitoring (Kubernetes probes, load balancers) and do not expose sensitive data.

​
Provider authentication

When Flowker calls an external service, it authenticates with the credentials on the provider configuration that the node calls through. Your platform credentials and your provider credentials stay separate. Supported authentication types: The config.auth block on the provider configuration holds the authentication the external service requires, as a { type, config } pair. Flowker applies it to every call a node makes through that connection. Flowker sends secret leaves in config.auth (an API key, bearer token, password, client secret, or HMAC secret) to the secrets backend. Flowker then removes them from the persisted configuration. With secret read-back configured, an authorized provider-configuration read can resolve them for display. Restrict that permission and treat its response as sensitive. Anything else you place in the configuration document (a header, for example) stays with the configuration, and a read can return it. Put each credential in config.auth. To rotate a secret, send the new value in an update. To keep the current one, omit the field or send it blank. This works while auth.type stays the same. An update that changes auth.type must carry a value for each secret the new type requires and the previous one did not. Otherwise, Flowker rejects it with FLK-0952. A change between two types that use the same secret, such as oidc_user to oidc_client_credentials, does not need that value again.
For OIDC flows (oidc_client_credentials and oidc_user), Flowker handles token acquisition and refresh automatically. For oidc_client_credentials, provide the issuer URL, client ID, and client secret. For oidc_user, provide the issuer URL, client ID, username, and password. client_secret is optional for public clients.

​
Network security

TLS:
  • Configure TLS termination for Flowker API traffic in your deployment.
  • Use https:// base URLs for external calls. Flowker accepts a URI for the generic HTTP provider’s base_url. It does not restrict it to HTTPS.
  • Transmit credentials and sensitive payloads only over encrypted links.
CORS configuration: Flowker supports configurable CORS settings:
  • Allowed origins are configurable per deployment
  • Cross-origin requests cannot carry credentials (AllowCredentials stays off)
  • Flowker caches preflight responses for performance

​
Resilience

Flowker protects against cascading failures from external services using circuit breaker and retry patterns. Circuit breaker: When an external service fails repeatedly, the circuit breaker opens and stops sending requests. This prevents your workflows from hanging on an unresponsive provider.
  • Transitions through closed → open → half-open states
  • Each circuit applies to one provider configuration and one tenant, so failures against one connection do not affect another
  • You configure thresholds globally (consecutive failures before opening)
  • The half-open state allows a limited number of test requests before fully closing
Retries: Flowker resolves the retry budget for each node with the first two rules. The failure class then decides whether that budget is spent:
  1. Node opt-in. A retry.max_attempts greater than 1 turns retries on whatever the method is. The value is the total attempt count, and the platform caps it at 5. A retry.max_attempts of 1 is not an opt-in. It sets a single attempt.
  2. HTTP method. With no opt-in, Flowker treats POST and PATCH as non-idempotent and gives them a single attempt. Every other verb retries, with 3 total attempts by default. This includes GET, HEAD, OPTIONS, PUT, and DELETE.
  3. Failure class. The budget is spent only on a transient failure: a network error, a timeout on the attempt, any 5xx status, or status 408 or 429. Every other 4xx fails on the first attempt however high the budget is. An open circuit and a cancelled execution also stop the loop. A request body over the configured size cap and a response body over the same cap stop it too.
Backoff is exponential with full jitter. Each wait is a random value between zero and a ceiling. The ceiling starts at 1 second and doubles on each attempt. retry.backoff_seconds sets the first ceiling, between 1 and 60. The random wait prevents many executions from retrying the same service at the same moment.

​
What’s next

Integration guide

Learn how to create provider configurations and connect external services.

Observability

Monitor Flowker with traces, metrics, and structured logs.