Universal Auth is NOT universal, please do not deprecate Service Tokens

[rwarford]

Feature description

Some existing tools will be unable to authenticate against the Infisical API using the current list of supported authentication methods, of which the "generic" solutions are Universal Auth and Kubernetes Auth.

Unfortunately both of those methods require an interaction step, a login to retrieve a token, then use of that token in subsequent API calls.

This would make it impossible to use tools like the External Secrets Operator.

The External Secrets Operator WebHook provider could authenticate with the Infisical API using a Service Token but cannot currently use "Universal Auth".

I imagine there are other similar scenarios where existing solutions would work with bearer token authentication but cannot easily use "Universal Auth".

Why would it be useful?

Why would this feature be useful for Infisical users?

The External Secrets Operator can transform Infisical Secrets into many useful different forms for Kubernetes. Using the External Secrets Operator would address issue #1072, for example.

It would be ideal to be able to create a bearer token for a Machine Identity and have that token automatically populate an Infisical Secret. The Infisical Kubernetes operator could then export that secret into a Kubernetes secret, which in turn could be used by the External Secrets Operator to authenticate against the Infisical API making it possible.

The ability to query multiple secretes in a single API call would also be very helpful in this scenario, making it very easy to create kubernetes basic-auth secrets and more.

[akhilmhdh]

Hey @rawkode

We have already worked with external secret operator to built an infisical provider that uses the universal auth quite fine.

We are moving away from service token because more customers wants to do multiple things with token and service token was never good for that due to permission and programmatic integration inside the app too. We haven't depreciated the service token yet and brainstorming more on this one for easiness on universal token usage.

Thank you for reaching out to express your concern over universal auth we will keep this consider in our future discussion too.

[akhilmhdh]

Changed to discussion as its not an issue

[rwarford]

Thank you, that's great news! I'll keep an eye on External Secrets and give the Infisical Provider a try as soon as it becomes available.

I was able use the Kubernetes Provider as a temporary work around.

[Real-Gecko]

Is this feature will be removed in self hosted too? Would be nice to have it in self-hosted at least.

[wildernessfamily]

I migrated over from Doppler because I prefer full control over my self-hosted containers and secrets. I chose Infisical. However, after reading the documentation and announcements, deprecating Service Tokens in favor of Machine Identities completely breaks least-privilege security for self-hosters and smaller teams. Which, in my opinion, is absolutely ridiculous.

Under the legacy Service Token model:

You create a project under Secrets Manager. You go to Access Control -> Service Tokens, and generate a token scoped strictly to an exact environment (Development, Staging, or Production) and a specific secret path. For example, my production notification container received a token that could ONLY read Production secrets for that exact app. If that container or token was ever compromised, the blast radius was strictly isolated. Zero cross-environment leakage, zero complex RBAC needed.

With the forced deprecation to Machine Identities:

1. When you attach a Machine Identity to a project using the standard built-in roles (Viewer/Member), it inherits read access across ALL environments (Development, Staging, and Production).
2. To lock an identity down to a single environment or secret path, you must create a Custom Role with granular permissions.
3. Custom Roles and granular RBAC are locked behind the Pro paywall ($18/identity/month).
4. Running a single VPS with 10–18 independent containers means you cannot responsibly share ONE machine identity across them without creating a massive blast-radius risk where one compromised container exposes credentials for every other workload.
5. If you follow standard security best practices and create an isolated Machine Identity per workload/environment, 18 containers * $18/identity/month = $324/month.

Charging $324/month just to regain basic environment-level isolation that Service Tokens provided for free is unreasonable.

Beyond the pricing, forced migrations consume massive amounts of engineering time for zero functional gain. Developers adopted Infisical under the premise of modern, open-source secret management. Forcing us to rewrite our deployment pipelines and container entrypoints just to land in an insecure posture—unless we pay enterprise ransom per container—is the exact kind of bait-and-switch that burned the community with Redis and Terraform.

Companies keep forgetting: this is open source. Developers do not have to accept hostile deprecations or paywalled security defaults. I will migrate back to Doppler, fork the codebase, or use modern AI-assisted engineering to build clean, unencumbered alternatives from scratch. Deprecating Service Tokens without providing native, free environment-level scoping for Machine Identities is a massive step backwards.