See Configuration: Authentication
Methods for details on how to
configure the various authentication methods.
Static Token
Thetoken
authentication method supports statically creating authentication tokens.
Once enabled, the /auth/v1/method/token
API prefix is mounted to Flipt’s API.
This section of the API supports the creation of static tokens.
Token Management
Tokens can be created and deleted via either the UI or API.API
The followingcurl
command creates a static token with no expiration.
Given authentication is set to required
then a prior client token will be required to perform this action.
UI
The UI also supports the creation and deletion of tokens. To access this functionality, navigate toSettings
from the main menu and see the ‘Static Tokens’ section.

Bootstrapping
On first startup, Flipt will automatically create a random static token with the nameinitial_bootstrap_token
if one doesn’t already exist and if token
authentication is enabled.

client_token
in the logs:
bootstrap.token
value in the configuration file. This is useful if you want to prevent having to search the logs after startup or if Flipt is deployed in an automated fashion, for example, if you are using a configuration management tool.
The bootstrap token can also be configured to have an expiration date by setting the bootstrap.expiration
value in the configuration file. This is useful if you want to ensure that the bootstrap token is only valid for a short time before automatically expiring.
See the Configuration: Method Token documentation for more details.
Token Expiration
Tokens can be created with an optional expiration date. This can be used to ensure that a token is only valid for a short time before automatically expiring. Expired tokens will be automatically deleted by Flipt. The interval and grace period for this cleanup process can be configured via thetoken.cleanup.interval
and token.cleanup.grace_period
values in the configuration.
Namespaced Tokens
Tokens can be created with an optional namespace to allow for more granular control over resource access. Namespaces allow for grouping resources such as flags, segments, etc. To learn more about namespaces, see the Concepts: Namespaces documentation. Namespaced tokens are useful for the scenario when you want to limit the privileges of an integration such as a CI/CD pipeline or internal service.It’s important to note that namespaced tokens offer limited access to the
Flipt API, as only API requests that can be scoped to a namespace are
supported.
/api/v1/namespaces/{namespace}/flags
endpoint supports a namespace
parameter, therefore a namespaced token can be used to access this endpoint. However, the /auth/v1/tokens
endpoint is not associated with a single namespace
, so a namespaced token cannot be used to access this endpoint.
This also means that namespaced tokens themselves cannot be used to create additional tokens. Tokens must be created using a non-namespaced (default) token.
OpenID Connect
OpenID Connect (OIDC) is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.Flipt’s UI is designed to support this authentication method natively.
Meaning, that once enabled, the UI will support login and present each provider as a login button.The rest of this information is mostly academic.
It’s mainly useful if you want to build your browser application using cookie authentication or understand Flipt’s OIDC flow at a lower level.See the OIDC Configuration documentation to learn how to configure your provider(s).
OIDC
authentication method is primarily designed to support browser-based authentication.
However, it can be manually invoked if such a use case presents itself.
Once enabled, the /auth/v1/method/oidc
API prefix is mounted to Flipt’s API.
This section of the API supports a generic OAuth 2.0 with OIDC flow.
Flipt’s configuration can be defined with multiple simultaneous OIDC providers.
An operator of Flipt chooses a name for each provider and then configures the relevant secrets necessary to authenticate with an OIDC client.
Numerous OIDC providers are available. For example, we’ve tested Flipt with:
- Auth0
- GitLab
- Dex
- Okta
- AzureAD
- Keycloak
Dex
and named it dex
(lowercase) in our provider configuration.
This will lead to the following endpoints being available on Flipt:
GET /auth/v1/method/oidc/dex/authorize
GET /auth/v1/method/oidc/dex/callback
flipt_client_token
and return it via the Set-Cookie
response header.
GitHub
GitHub is an OAuth 2.0 implementation compatible with GitHub.As with OIDC, the GitHub method works natively with the Flipt UI. Once
enabled, the UI will support a “Login with GitHub” login option.
GitHub
authentication method is primarily designed to support browser-based authentication.
However, it can be manually invoked if the need arises.
Once enabled, the /auth/v1/method/github
API prefix is mounted to Flipt’s API.
This section of the API supports GitHub’s OAuth 2.0 flow.
This will lead to the following endpoints being available on Flipt:
GET /auth/v1/method/github/authorize
GET /auth/v1/method/github/callback
flipt_client_token
and return it via the Set-Cookie
response header.
Kubernetes
This method is designed for automatically authenticating applications with
Flipt.
kubernetes
authentication method supports the ability to exchange Kubernetes service account tokens with Flipt for client tokens.
This allows services deployed into the same Kubernetes cluster as Flipt to automatically gain authenticated access to the Flipt API without additional management of static client tokens.
Kubernetes refreshes service account tokens locally, all that’s required is to
read the token from the disk again.
Via the SDK
Some of our SDKs support automatic authentication via the Kubernetes authentication method. These clients do not require you to have to manually invoke the verify service account API. Instead, they do this operation for you, and they ensure that the retrieved client token from Flipt is automatically refreshed. The SDKs that currently support this include:Via the API
Acquiring a client token via this method can be performed manually from inside a pod. The following usescurl
to illustrate how a local, valid service account token can be used in this way.
JSON Web Tokens
JSON Web Tokens (JWT) are an open, industry-standard RFC 7519 method for representing claims securely between two parties. Flipt supports the use of externally created and signed JWTs as a method of authentication. JWT authentication is useful for scenarios where you want to integrate Flipt with an existing authentication system, or where you want to perform service to Flipt authentication without the need to manage static client tokens.JWT authentication is not supported by the Flipt UI as it is not a
session-compatible authentication method.