HTTP
Client tokens can be presented via HTTP requests in two different valid ways. This choice allows us to support two different types of workloads.1. Authorization Header
For applications that communicate with Flipt over HTTP, the Authorization header is most appropriate.
It must be provided in the form Authorization: Bearer <client_token>.
The following examples illustrate this in the context of various programming languages:
2. Cookie Header
It’s important to enable CSRF
prevention in your Flipt configuration when using a “session compatible”
authentication method and
Cookie based authentication in the browser.Cookie called flipt_client_token.
Set-Cookie response header during the authentication method exchange.
In a browser context this means subsequent API calls will be automatically authenticated given the API requests are invoked with credentials included (cookies are enabled). Flipt’s UI leverages this mechanism for its login functionality.
GRPC
For gRPC we use the Metadata functionality similar to HTTP Headers. The lower-caseauthorization metadata key should be supplied with a single string Bearer <client-token> to any RPC calls.
Example
The following example authenticates a single gRPC client request:rpc.go
interceptor.go