Hi!

First of all, great project! Customizable, scalable, metrics support… love it!
One thing I'm a bit confused about is the authentication setup.

If this tool is to be used as a feature-flag service, your service should be able to evaluate a flag.
Once you enable authentication however, ALL API routes are blocked off, including the evaluate one.
If you give your service a static token for example, it now suddenly has full CRUD access to everything, which you definitely don't want.

So ideally you only want authentication on the whole CRUD setup, but evaluation of flags should always work.

Am I missing something? What is the reasoning behind this implementation?

Thanks!

Hey Daan 👋 Thanks for the kind words. Hopefully I can shine a light on the auth concerns.

Today, Flipt is all or nothing with regards to enabling API authentication. As you mentioned, a static client token has full API access. So enabling auth means giving your services access to all API routes and it also means requiring a session compatible method (OIDC is all we have at the moment) in order for the UI to work.

Our thoughts going forward are to ultimately implement first class authorization support. Which I believe would address your concern here (correct me if I am wrong).
We haven't fully fleshed out the design yet. But you could imagine being able to scope a static token or describe a restricted policy when acquiring a client token. One which only has access to say evaluation or reading flag state.

However, today our API is all or nothing I am afraid.
Does this answer your question?

We're curious to hear feedback like this as it all feeds into the design process for that feature 🙏 .

Hi! Thanks for taking the time in writing such a detailed reply.

Yes, tokens with scope support is something that would solve/address my issues with the current authentication setup.

However for the time being, I'm thinking about a setting that enables/disabled public access to the evaluate endpoint.
This way you can block off full CRUD access behind something like SSO, but services are always able to evaluate their flags.
This seems like a quite common use-case in my opinion, perhaps others might benefit from this as well.

Thanks!

Nice, thats a good thought. I believe we do have some users that deploy multiple instances of Flipt with different configurations in this way.
Also with load balancer rules to expose e.g. only the read or flag potions of the API to services or to make a read only view in the UI.
Totally a reasonable way to mitigate the current lack of authorization control 💯 .

Ofcourse, all of this is solvable with some loadbalancer rewrite magic but before I go that route I was evaluating some more native solutions.

While I have you and we're talking auth, and I am assuming you're a k8s user (thanks for the Helm PR 🙏 ) we're about to land support for authenticating using Kubernetes service account tokens in 1.19.

The idea is your services can exchange a service account token for a flipt client token in an initial handshake on your application start.
This is so you don't need to create static tokens and distribute or rotate them.
A bit of client-side glue will be required. Or we're considering writing a sidecar that can do this automatically and proxy to Flipt.

Is this something that might be of interest to your use-case?
Ultimately this is something we would want to tie into an authz solution too. So those are scoped to e.g. the flag evaluation operation.

Yup, definetely running on k8s :p & always happy to help some OS projects.

I saw the k8s svc account PR, which does sound super neat but again… still all or nothing.

What we're currently trying to do is use this as a general feature-flag service for both frontend and backend applications. Managed via SSO login.
But for frontend applications to be able to use the flags securely:

• they need to proxy their request to a backend service which only exposes/redirect the evaluate endpoint and attaches the static token
  OR
• the evaluate route needs to be public

So currently the latter sounds more convenient, because proxies add uneccessary overhead.
Going through the code to see if that it's something that would be hard to implement

That makes total. Thanks for sharing that use-case 🙏

I'm not fully familiar with the code-base yet, but would it be hard to implement such a middleware/auth rule?
Basically disabling auth on that one endpoint based on a setting.

I don't think that would be difficult to add to Flipt in the way you describe.
My one concern is how the design of such a feature plays out and how well it would work long term with any visions we have for authorization.

One of those; we could just do that today, but how does this feature look in the coming months when we may look to build a whole authorization system which supersedes it? kind of question comes to mind.

The way I see it is that my 'solution' is more of a temporary thing to serve that use-case.
Once a more fine-grained access token exists, this can be deprecated. (Which would indeed be a breaking change)

The token system is better in every single way, but depening how far away on the roadmap that is, it might be worth to add this solution first and remove it later. Given that it is not that much development overhead to begin with.

We can definitely think through what the configuration would look like to support this and open an issue to discuss it with you.

As you say, it might be a while till we support that. We're about to work on namespaces first (in Flipt namespaces) which we see as a precursor to authz.

> We can definitely think through what the configuration would look like to support this and open an issue to discuss it with you.
Awesome! Willing to help myself but not that familiar with the GRPC stuff 😅

Again, not trying to push the agenda of the project in any way… you guys are obviously doing a good job! 😅
But my thinking was, if I run into this (which seems like not such a special case) other people are as well.
Which might drive adoption a little bit 🙂

💯 really appreciate you coming and sharing your use-case. We know that frontend is something Flipt can do better to support.
So if something like this bridges the gap for yourself and others it is worth exploring.

Awesome! thanks 🙂 Looking forward to see which features the future brings

Want me to open an issue for this? (don't want to create unnecessary noise if something like this won't be considered in the first place)

Oh yes please 🙏 That would be greatly appreciated. All issues welcomed.