This document describes the various supported authentication methods.
token
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.
curl
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.
Settings
from the main menu and see the ‘Static Tokens’ section.
initial_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.cleanup.interval
and token.cleanup.grace_period
values in the configuration.
/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.
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:
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
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
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.
curl
to illustrate how a local, valid service account token can be used in this way.