SAML Authentication

SAML 2.0 single sign-on lets your team sign in to sfp with your corporate identity provider — Microsoft Entra ID, Okta, Google Workspace, OneLogin, PingIdentity, and similar.

This area of the docs covers everything you need:

PageWhat it covers
Identity ProvidersConfigure your IdP. Same steps for self-hosted and cloud deployments — only the URLs differ.
Self-Hosted SetupWire the IdP into a deployment you run yourself (sfp server init).
Cloud SetupWire the IdP into a flxbl-managed cloud deployment.
TroubleshootingCommon errors and how to fix them.

Which deployment mode am I in?

Run this against your sfp server to find out:

curl https://<your-domain>/sfp/api/config
deploymentMode fieldFollow
selfhostedSelf-Hosted Setup
cloudCloud Setup

If you provisioned the server with sfp server init, you are self-hosted.


Prerequisites

Both modes need the same things:

  • A running sfp deployment (V3 or later) reachable over HTTPS.
  • Admin access to your identity provider.
  • An owner-level JWT for the sfp API. Sign in as the tenant admin to get one:
    sfp auth login --admin --email admin@<tenant>.local

What's automated

For deployments created with sfp server init (V3+), SAML is enabled out of the box. There is no manual config-file editing required to turn it on:

  • Signing material is generated during sfp server init.
  • The IdP is registered through an HTTP API — no restart needed.
  • The provider ID and SSO domain are auto-published to every client (CLI, web app, desktop app) via /sfp/api/config.

The only manual steps are configuring the IdP, registering it through the API, and provisioning users. Those are what the setup guides walk through.


High-level flow

Whichever mode you're in, the path is the same:

  1. Configure your IdP — create an application, set the SAML URLs, copy the federation metadata URL. See Identity Providers.
  2. Register the IdP with sfp — one API call. The server picks it up immediately.
  3. Provision usersPOST /sfp/api/users (or sfp server user add). Self-registration is disabled by default; users must be created before they can sign in.
  4. Sign in — from the CLI, web UI, or desktop app. The SSO domain is auto-detected from the server config; users just click Continue.

On this page