OAuth / delegated authorization for third-party integrations

[keksmd]

Describe the feature or potential improvement

It would be useful if Langfuse could act as an OAuth authorization server for third-party applications, allowing users to grant an external platform scoped access to their Langfuse organization.

The desired UX would be similar to "Connect GitHub", "Connect Slack", etc.:

1. User clicks Connect Langfuse in a third-party platform.
2. User is redirected to Langfuse.
3. User selects/authorizes their Langfuse organization.
4. Langfuse redirects back with an authorization code.
5. The application exchanges it for a scoped access token.
6. The application can then provision/manage Langfuse resources inside the user's organization.

For example:

Third-party platform
        |
        | Connect Langfuse
        v
Langfuse authorization page
        |
        | user grants access to Organization X
        v
OAuth callback
        |
        | scoped access token
        v
POST /projects
POST /projects/{id}/apiKeys
        |
        v
Project created in Organization X

Use case

We are building a platform where users can deploy AI agents.

We want users to be able to enable Langfuse observability for an agent without manually:

• creating a Langfuse project;
• navigating to project settings;
• generating API credentials;
• copying the public key;
• copying the secret key;
• pasting both credentials into our platform.

Ideally, the experience would simply be:

Connect Langfuse → select organization → done.

Our platform could then create a dedicated Langfuse project and project API key for the deployed agent.

Importantly, the project should belong to the user's Langfuse organization, not to an organization owned by our platform.

Why existing API authentication does not solve this

Langfuse already exposes project-level and organization-level APIs, which provide most of the required provisioning functionality.

However, API authentication currently requires credentials to already be created and transferred to the integrating application.

Using our own organization API key would mean creating all customer projects inside our Langfuse organization, which is not desirable.

Asking every customer to manually generate and paste an organization-level credential technically works, but results in significantly worse UX and requires the third-party application to receive a powerful long-lived credential.

What seems to be missing is the delegation layer between the user and these existing APIs.

Proposed solution

Support OAuth 2.0 authorization for third-party applications.

For example, an application could request scopes such as:

org:read
projects:read
projects:create
projects:write
api-keys:create
api-keys:revoke

A flow could look roughly like:

GET /oauth/authorize
    ?client_id=...
    &redirect_uri=...
    &scope=org:read projects:create api-keys:create
    &state=...

→ user authenticates with Langfuse
→ selects an organization
→ reviews requested permissions
→ approves

GET https://third-party.example/callback?code=...&state=...

POST /oauth/token

→ short-lived access token
→ optionally refresh token

The resulting token would be restricted to the selected organization and granted scopes.

The third-party platform could then use the existing organization/project management APIs with that token.

Benefits

This would enable integrations such as:

• AI platforms automatically provisioning Langfuse projects;
• agent platforms connecting observability with one click;
• CI/CD platforms provisioning Langfuse resources;
• developer platforms offering "Connect Langfuse";
• SaaS products integrating with a customer's existing Langfuse organization without asking for long-lived organization credentials.

It would also be safer than asking users to copy organization-level API keys into third-party services, since access could be scoped, revoked independently, and potentially use short-lived tokens.

Alternatives considered

Organization API key owned by the integrating platform

This creates customer projects inside the integrating platform's Langfuse organization instead of the customer's organization.

User manually provides an organization API key

This works technically, but requires users to manually create/copy credentials and gives the integration a powerful long-lived credential.

User manually creates a project and provides project keys

This avoids organization-level access but prevents automatic project provisioning and produces an unnecessarily complicated onboarding flow.

Additional information

Langfuse already has the APIs required for much of the actual resource provisioning. The requested feature is primarily a delegated authorization mechanism allowing those APIs to be safely used on behalf of a Langfuse user/organization.

Happy to provide more details about our integration use case or help test an implementation.

[pacocartones]

The delegation layer would improve the credential boundary, but the current public API surface suggests one prerequisite: OAuth alone would not yet enable the full flow in the diagram.

In the current tree:

• Basic auth carries project or organization API-key authority.
• Bearer auth is deliberately limited and rejects organization-scoped keys.
• /api/public/organizations/projects and /api/public/organizations/apiKeys require organization scope, the admin-api entitlement, and currently expose GET only.

So I would split the design into two contracts:

1. Delegated grant: authorization-code flow with PKCE, exact redirect URI matching, short-lived access tokens, rotating refresh tokens, organization binding, consent receipt, independent revocation, and a public client identifier.
2. Delegated management API: explicitly scoped create/delete operations with least-privilege permissions and audit events. Avoid mapping a broad OAuth scope directly onto the existing all-powerful organization key semantics.

For the stated onboarding flow, a narrowly scoped operation may be safer than returning a reusable project secret to the third party:

projects:create
project-credentials:create
project-credentials:rotate
project-credentials:revoke

The consent screen should name the selected organization and clearly distinguish "create a project" from "create credentials that can ingest/read data." If possible, create an installation/service-principal object per integration so its projects, keys, last use, and revocation are auditable independently of the human who approved it.

One product question appears to be decisive: should delegated provisioning be part of the OSS/public API, or remain tied to the existing admin-api entitlement? That decision determines whether this is primarily an OAuth feature or also a public management-API expansion.