Once authentication has been set to
required: true all API routes will require a client token to be present.
The UI will require a session-compatible authentication method (e.g. OIDC) to be enabled.
Flipt supports the ability to secure its core API routes by setting the
required field to
true on the
authentication configuration object.
authentication: required: true
When authentication is set to
required, the API will ensure valid credentials are present on all API requests.
See the Authentication: Overview documentation for more details on Flipt’s API authentication handling.
This section contains common properties for establishing browser sessions via a “session compatible” authentication method. Session-compatible methods enable support for login in the UI. The methods below state whether or not they are session compatible (e.g. OIDC is session compatible).
In order to establish a browser session over HTTP (via a
Cookie header) some configuration is required.
authentication: session: domain: "flipt.yourorg.com" secure: true csrf: key: "some_secret_string"
When a “session compatible” authentication method is enabled the
domain property is required.
It should be configured with the public domain your Flipt instance is hosted on.
The other properties are not required to be explicitly configured.
To best secure your instance of Flipt, we advise that you run Flipt with
This will require you to expose Flipt over HTTPS.
Additionally, we advise that you configure a
csrf.key with a 32 or 64-byte random string of data.
Using openssl to generate a 64-byte CSRF key
openssl rand -base64 64
Each key within the
methods section is a particular authentication method.
These methods are disabled (
enabled: false) by default.
Enabling and configuring a method allows for different ways to establish client token credentials within Flipt.
Method: Static Token
token method provides the ability to create client tokens statically, with optional expiry constraints.
authentication: methods: token: cleanup: # (see "Common Properties: Cleanup" below) enabled: true
Once enabled, static tokens can be created via the CreateToken operation in the API.
Further explanation for using this method can be found in the Authentication: Static Token documentation.
session compatibleauthentication method.
oidc method provides the ability to establish client tokens via OAuth 2.0 with OIDC flow.
Once enabled and configured properly, the UI will automatically leverage it and present any configured providers as login options.
authentication: methods: oidc: cleanup: # (see "Common Properties: Cleanup" below) enabled: true providers: some_provider: # insert your provider name here issuer_url: "https://some.oidc.issuer.com" client_id: "some_client_identifier" client_token: "some_client_secret_credential" redirect_address: "https://your.flipt.instance.url.com" scopes: - email - profile
Multiple providers can be configured simultaneously. Each will result in a Login option being presented in the UI, along with a separate endpoint being added in the API to support each provider flow.
Flipt has been tested with each of the following providers:
Though the intention is that it should work with other OIDC providers, these are just the handful the Flipt team has validated.
Following any of the links above should take you to the relevant documentation for each of these providers’ OIDC client setups. You can use the credentials and client configuration obtained using those steps as configuration for your Flipt instance.
Example: OIDC with Google
Given we’re running our instance of Flipt on the public internet at
Using Google as an example and the documentation linked above, we obtained the following credentials for a Google OAuth client:
client_id: "CyJcdvQMadOjSEx7ArArom0ytrbIHWd2Fb3N59oh8NQ=" client_token: "WGgJmfQqN7cf17dFyZKXDL5S445/qhp+hfDAC0Mnl7oBrxgdAgiMyuwCkPiwfgQy"
We could create a provider definition in our configuration like so:
authentication: methods: oidc: enabled: true providers: google: issuer_url: "https://accounts.google.com" client_id: "CyJcdvQMadOjSEx7ArArom0ytrbIHWd2Fb3N59oh8NQ=" client_token: "WGgJmfQqN7cf17dFyZKXDL5S445/qhp+hfDAC0Mnl7oBrxgdAgiMyuwCkPiwfgQy" redirect_address: "https://flipt.myorg.com" scopes: - email - profile
scopes such as
profile are not 100% necessary, however, adding
them will result in Flipt being able to identify more details about your users
such as personalized greeting messages and user profile pictures in the UI.
Once this configuration has been enabled a
Login with Google option will be presented in the UI.
Clicking this button will navigate the user to a Google consent screen.
Once the user has authenticated with Google, they will be redirected to the address defined in the
redirect_address section of the provider configuration.
Google’s consent screen can be configured to only accept accounts that are within your Google Workspace organization.
Other providers have similar mechanisms for attenuating who can leverage this authentication flow.
Common Properties: Cleanup
Each authentication method contains a nested
cleanup configuration object.
This object configures the periodic deletion of expired authentications created with the associated method.
authentication: <method>: cleanup: interval: 10m grace_period: 24h
The cleanup object currently contains two keys
interval is used to configure how frequently a delete expired tokens action is performed.
grace_period is used to ensure that expired tokens are preserved for at least this configured duration.
This allows you to keep authentications around for auditing purposes after expiration.
Expired tokens are instances where the
expires_at timestamp occurs before the current time.
The grace period is added onto this timestamp as a predicate when the delete operation is made.
Tokens that have expired (
expires_at is before
now()) will begin immediately failing authentication when presented as a credential to the API.
grace_period is simply for the cleanup process.
It is possible to secure Flipt simply by running it behind a reverse proxy in your own trusted environment. An example of this can be found in the core Flipt repository here.
Currently, Flipt only supports authentication without any extended authorization capabilities. Authorization is something we’re actively exploring and we will update this section as we settle on a design.
We would appreciate your input into designing authorization. Head over to our discord and let us know what you need from Flipt.