> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.
# Security
> Protect Flowker workflows, data, and integrations with API Key authentication, per-executor credentials, and HTTPS-enforced endpoints.
export const GDSL = ({children}) =>
{children}
;
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
***
All Flowker API endpoints are protected by a **unified API Key middleware**. Every request must include a valid API Key in the `X-API-Key` header.
```bash theme={null}
curl -X GET https://your-flowker-instance/v1/workflows \
-H "X-API-Key: your-api-key"
```
**How it works:**
* The middleware validates the API Key on every request before processing
* Authorization is binary — a valid API Key grants full access to all endpoints
* API Keys are configured via environment variables or bootstrap configuration
* Invalid or missing keys 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.
The current release uses a single API Key for all endpoints. Role-based access control and policy-based authorization (via Access Manager) are planned for future releases.
## 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 |
Authentication credentials are stored in the executor configuration and used automatically when the executor is called during workflow execution.
```json theme={null}
{
"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`](/en/reference/flowker/search-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`](/en/reference/flowker/verify-audit-hash-chain) 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](/en/reference/flowker/search-audit-events).
## What's next
***
Learn how to configure executors and connect external services.
Monitor Flowker with traces, metrics, and structured logs.