Back to Blog Series
Part 11: Security ControlsStep 11 of 15SecurityAuthCredentials

Security Architecture: Auth, Credential Vault, API Keys, and Access Control

How I secured Fluxo across account auth, encrypted credentials, RBAC enforcement, programmable API keys, and signed integration surfaces.

Why this part is here in the storyline

Review the auth, vault, token, and access-control layers that secure the platform.

Artem Moshnin, Lead Software EngineerJanuary 29, 202614 min
Series Progress11/15

Fluxo workflows can touch credentials, send messages, write to databases, and expose public review links. That means security is not an enterprise add-on. It is baseline infrastructure.

I designed Fluxo’s security model to be composable: authentication, organization scoping, RBAC, credential encryption, API keys, and signed webhooks all align to the same tenant boundary. When those layers agree, new features inherit the same guarantees instead of inventing their own rules.

Section 1

Authentication and identity

#authentication-and-identity

Fluxo uses Better Auth with:

  • email/password auth
  • trusted social providers (Google, GitHub, Dropbox)
  • account linking
  • session-backed protected procedures

Every protected request resolves active organization context server-side before business logic. This prevents cross-tenant access bugs and keeps authorization logic consistent.

Section 2

Credential vault

#credential-vault

Credentials are encrypted at rest using an application encryption key before persistence. At runtime, decrypt happens only where needed for provider calls.

I also enforce credential type alignment so a node cannot accidentally use an incompatible credential class.

Section 3

Access control layers

#access-control-layers

I enforce access at multiple levels:

  • role-level guards (OWNER, ADMIN, PARTICIPANT, REVIEWER)
  • asset-level selected permissions for workflows and credentials
  • operation-level checks (view vs edit)

Reviewer role is constrained by design to avoid accidental privilege bleed.

Section 4

API keys for programmable access

#api-keys-for-programmable-access

I implemented organization-scoped API keys with:

  • hash-only storage
  • one-time raw key reveal
  • prefix display for management
  • scopes (review read/write/approve and webhook scopes)
  • revoke and expiry controls

Request auth uses bearer key verification, scope checks, and last-used timestamp updates.

Section 5

Secure webhook delivery

#secure-webhook-delivery

Outgoing review webhooks are signed with HMAC SHA-256 per endpoint secret and include delivery ids. Delivery attempts are persisted with response status/body and retry metadata.

Section 6

Signed review actions and sessions

#signed-review-actions-and-sessions

For public review links and quick actions, I use hashed tokens with expiration and usage tracking. Session actions log actor label, IP, and user-agent for auditability.

Section 7

Why this model scales

#why-this-model-scales

Security in Fluxo scales because it is consistent. Auth, org context, role checks, and tokenized external access all align to the same organization boundary. That consistency is what keeps new features secure by default.