Skip to content
flui.cloud

Identity and OIDC

Identity is the place where many self-hosted platforms quietly install a user/password table and call it done. Flui takes a different approach: it delegates identity to a real OIDC provider running on the control cluster, with everything that comes with that — sessions, federation, machine accounts, password reset, MFA. There is no Flui-maintained user database; the authority for who can sign in is the identity provider, and Flui uses what it issues.

The problem identity has to cover

The control plane of an installation needs to handle:

  • Sign-in for the platform — the dashboard, the CLI, the API.
  • Sign-in for the applications deployed on the platform.
  • Long-lived access for automation: CI pipelines, scripts, third-party integrations.
  • Eventually federation with corporate identity providers.
  • Account lifecycle work that nobody wants to write: password reset, MFA, audit log of sign-in events.

Building any one of these is plausible. Building all of them and keeping them maintained for years is not. So Flui delegates the whole stack to an OIDC provider.

How it works

The identity provider is installed on the control cluster alongside the rest of the platform and serves as the single sign-on authority for everything the installation runs.

What this gives the user out of the box:

  • One login that covers the dashboard, the CLI and the API.
  • Long-lived machine-to-machine keys for automation, scoped and revocable independently of any human user.
  • A foundation that can later be wired to a corporate identity provider — federation is a configuration change on the identity provider, not a Flui code change.

The interactive login is a short, well-known dance: the CLI or dashboard sends the user to the identity provider, the user authenticates, and the result is a session the platform trusts.

On the roadmap, the same identity provider becomes the OIDC authority for the applications deployed on the platform too: the framework templates Flui ships, and any custom application that wants it, will be able to plug into the installation’s identity provider with no per-app configuration on the operator’s side. The end state is “the user logs in once and that login is good for every Flui surface and every app on the installation”.

How flui auth login works

The CLI needs an authenticated session for every operation that acts on a cluster — anything that reaches the Flui API of an installation. Read-only local commands (managing contexts, inspecting configuration) do not.

To get that session, the user runs flui auth login. The CLI opens a browser to the installation’s identity provider, the user authenticates there, and the CLI receives the result back through a local callback. At that point the CLI does not keep using the short-lived OIDC bearer the flow produced: it immediately exchanges it for a long-lived machine-to-machine key identifying the workstation, and saves that key in the active context. From then on the CLI authenticates with that key, and the interactive login is run only when the user explicitly logs in again.

The reason for the swap is straightforward: the OIDC bearer is short-lived by design (minutes), and the CLI needs a session that lasts as long as the user is working. A named M2M key gives that, and can be revoked on its own without touching the human user it was issued for.

Where this chapter goes from here

  • The control cluster — the identity provider as a platform component on the control cluster.
  • CLI: Authentication — the command-by-command reference for logging in and generating machine-to-machine keys.