Security

Flowker protects your workflows, data, and integrations through Access Manager authentication and per-connection credential management. Lerian serves the API over TLS. This page covers the security model as implemented in the current release.

Platform authentication

Flowker delegates platform authentication to Access Manager. 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.

curl -X GET https://your-flowker-instance/v1/workflows \
  -H "Authorization: Bearer <token>"

Invalid or missing credentials return 401 Unauthorized.

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:

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
`hmac`	Request signing with a shared HMAC secret	Providers that verify a request signature header

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. A read never returns the credential the authentication type declares. Store credentials only in the fields the authentication type declares. 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.

{
  "config": {
    "auth": {
      "type": "bearer",
      "config": {
        "token": "eyJhbGciOiJSUzI1NiIs..."
      }
    }
  }
}

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:

Lerian terminates TLS for Flowker API traffic.
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 applies these CORS rules:

Only allowed origins can call the API from a browser. To add an origin, contact Lerian support
Cross-origin requests cannot carry credentials (AllowCredentials stays off)
Preflight responses tell the browser to cache them for one hour

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
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:

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.
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.
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.

Overview

Guides

Console

Operations

Platform authentication

Provider authentication

Network security

Resilience

What’s next

Integration guide

Observability

​Platform authentication

​Provider authentication

​Network security

​Resilience

​What’s next

Integration guide

Observability

Platform authentication

Provider authentication

Network security

Resilience

What’s next