1. Methods

See Configuration: Authentication Methods for details on how to configure the various authentication methods.

Static Token

When token method is enabled and no static tokens exist in the backing store, an initial token is created and logged in Flipt’s server output.

The 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.

Example: Token Creation

The following 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.

curl -X POST localhost:8080/auth/v1/method/token \
    -H 'Authorization: Bearer gt6P_zIqTnCngfHDCpWb48ob5EBt3PqunUhpofNCNnc=' \
    -H 'Content-Type: application/json' \
    --data '{"name":"access_all_areas","description":"keys to the castle"}'

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.

Flipts own UI is designed to support this authentication method natively. Meaning, once enabled, the UI will support login and present each provider as a login button.

The rest of this information is mostly academic. It is mainly useful if you want to build your own browser application using cookie authentication or understand Flipt’s OIDC flow at a lower level.

Head over to OIDC Configuration documentation to learn how to configure your provider(s).

The 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.

There are many OIDC providers out there. For example, we have tested Flipt with:

  • Google
  • Auth0
  • Gitlab
  • Dex

Each provider has their own way of establishing clients and acquiring the relevant credentials. You can find further documentation on leveraging providers like these in our OIDC Configuration documentation.

For illustration purposes, let us say we have configured a single provider 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

These two endpoints are necessary to support the different legs of the OAuth/OIDC flow. The first can be requested to obtain an authorization URL directed at the configured instance of Dex. The latter is the destination that Dex will redirect the client back to. When using HTTP, this callback endpoint will establish the flipt_client_token and return it via the Set-Cookie response header.