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