Support short lived credentials for infrastructure dependencies

[Oscmage]

Describe the feature or potential improvement

Many organizations are moving away from static credentials in favor of identity based authentication and short lived access tokens.

Our primary use case is Azure, where services can authenticate to managed infrastructure using Managed Identity instead of storing long lived secrets. This pattern is increasingly common across databases, caches, object storage, and other managed services.

Langfuse currently appears to assume static credentials for infrastructure dependencies such as PostgreSQL and Redis/Valkey. This makes it difficult to deploy in environments where long lived credentials are discouraged or not permitted.

Would the team be open to supporting short lived credentials and credential refresh for infrastructure dependencies?

Azure Managed Identity is our primary use case, but the same capability would also benefit users of AWS IAM based authentication, GCP Workload Identity, and other systems that issue temporary credentials.

This would make Langfuse easier to deploy in cloud native and regulated environments while reducing the operational burden of managing and rotating long lived secrets.

Additional information

No response

[jannikmaierhoefer]

Thanks for adding this @Oscmage!

[Steffen911]

@Oscmage Could you share a bit more on your ideas on how you'd approach this? We'd be happy to accept contributions, but I want to ensure that any chosen approach would be long-term maintainable for us.

[Oscmage]

@Steffen911 here is the approach I would propose. The core idea is a small provider interface that isolates the only part that is specific to a cloud, minting a token, behind one method, so everything else (caching, refreshing, wiring) is shared and works the same for any provider:

interface ManagedCredentialProvider {
  readonly name: string;        // e.g. Azure Managed Identity, file, ...
  readonly username?: string;   // e.g. the managed identity object id for Azure Redis
  fetchToken(): Promise<{ token: string; expiresOnTimestamp: number }>;
}

Three layers around it:

1. Provider: implements fetchToken() for one backend (Azure Managed Identity, later AWS IAM or GCP). Thin, and the only piece that knows about a specific cloud.
2. RefreshingTokenManager: works for any provider. It caches the token, refreshes it before it expires, and collapses concurrent fetches into one.
3. Binding: applies the token to a specific dependency. For Redis it sets the password and sends a fresh AUTH on refresh. For Postgres it feeds the token into the connection password callback.

flowchart LR
  subgraph P["Providers (mint a token)"]
    direction TB
    AZ["Azure Managed Identity"]
    AWS["AWS IAM (planned)"]
    FILE["file (generic, no SDK)"]
  end
  subgraph C["Generic core"]
    direction TB
    IFACE["ManagedCredentialProvider.fetchToken()"]
    MGR["RefreshingTokenManager<br/>cache and refresh before expiry"]
    IFACE --> MGR
  end
  AZ --> IFACE
  AWS --> IFACE
  FILE --> IFACE
  MGR --> RB["Redis binding"] --> REDIS[("Redis")]
  MGR --> PB["Postgres binding"] --> PG[("Postgres")]

Loading

This way, adding a cloud or auth method is one small provider, and adding a dependency is one small binding. Existing setups are unaffected: the method defaults to static, which skips all of this and keeps today's username and password path exactly as it is, so the change is purely additive and off by default.

On maintainability, I looked into how other open source projects solve this before settling on the shape above. I leaned on an LLM to survey the prior art, so the specifics are worth a sanity check, but the pattern was strikingly consistent:

• Redis official Node client and its Entra ID package: the same split, where an identity provider feeds a token manager that refreshes before expiry. This is the closest analogue since it is TypeScript and Redis.
• Apache Airflow: refreshes AWS RDS IAM tokens at the moment a new connection is created, which maps directly onto the Postgres approach.
• AWS Advanced JDBC and Python wrappers: pluggable credential plugins with a token cache and a refresh buffer kept under the token lifetime.
• Grafana: a per cloud selector (auth type, then factory, then provider), with caching and refresh living in the provider layer.

They all converge on the same shape: the provider mints, the manager caches and refreshes early, and the consumer authenticates again. That consistency is what gives me confidence it is a maintainable shape rather than something bespoke.

A couple of specifics from that research:

• Dependencies: Azure is the only new one (@azure/identity), and it is loaded lazily, so it is not pulled in unless that method is selected. AWS and GCP would reuse SDKs already in the tree. I would also include a dependency free file provider (read the token from a path that an external rotator keeps fresh, such as Vault Agent, a CSI driver, or a workload identity sidecar) for the cloud neutral case.
• Redis vs Postgres: Redis works inside the app cleanly. Postgres needs Prisma's driver adapter so we can supply a pg pool with an async password callback. The same RefreshingTokenManager plugs straight in.

I have a working proof of concept for the Redis path (Azure Managed Identity, with local tests that mock the Azure SDK, so no cloud resources are needed) and can open a PR if this direction looks right, then follow up with Postgres. Does this match what you had in mind for maintainability?

[Steffen911]

@Oscmage This sounds great! The concept seems sound and I also agree that doing Redis and Postgres in separate PRs makes tons of sense. Please ping me here once you have a contribution that's ready for review and thank you so much 🙏

[Oscmage]

#14325

[Steffen911]

@Oscmage Apologies for the delay and thank you for the addition! Looks good to me and is merged!