Per-user provider credentials: using a seat subscription from your own apps

[MattJackson]

The problem

Increasingly, the credential that grants AI access belongs to a person, not to a deployment.

Developers hold seat subscriptions (ChatGPT Pro, Claude Max, Copilot) that sit mostly idle, while the same person separately pays per-token for API access from their own apps. The obvious ask is "let my applications use the seat I already have."

Busbar today assumes the other model: a provider has one credential (api_key), resolved once at startup, and every caller's traffic spends it. That is correct for "the company pays". It does not express "each person's own subscription pays".

This issue is to work out what Busbar should do about that. Opening it because the question came up in #41 and the answer is bigger than that thread.

What works today

upstream_credentials: passthrough. The calling application runs its own sign-in flow, holds and refreshes the user's token, and presents it per request. Busbar forwards it upstream instead of using its own key.

This is shipped, and it is arguably the right layering. The credential belongs to whoever owns the user's session, and the app already has the browser, the login UI and the refresh timer. Busbar keeps routing, failover, metering and policy. Governance is unaffected: Busbar still authenticates the caller with its own key, so per-user budgets, rate limits, pool restrictions and cost visibility all still work.

Two things it cannot do:

1. Act when the user is absent. No background job or scheduled agent working on someone's behalf, because there is no stored credential to use.
2. Work with off-the-shelf clients. Cursor, VS Code and similar know how to send an API key. They do not implement OAuth, and they should not have to.

What is missing, and what is actually blocked

Worth separating these, because only one of them is blocked and it is not the expensive one.

The credential lifecycle. Provider-agnostic, and buildable today:

• per-caller credential storage, encrypted at rest
• refresh-before-expiry with single-flight (when a token expires and N requests notice at once, exactly one refresh should happen and the rest wait on it)
• per-caller credential selection on the request path, cheap enough not to move the latency numbers
• per-caller failure isolation, so one user revoking consent fails that user's requests rather than the pool
• a "connect an account" completion for the hosted sign-in flow Busbar already has

A specific provider's OAuth client. Needs a client registration and a public endpoint from that provider.

Busbar already ships the OAuth ceremony itself: authorization-code with PKCE, state and nonce validated before identity is established, callback handling, and a multi-hop token-exchange loop, all behind the kind: auth plugin ABI. It is currently pointed inbound. It is how a developer signs in to Busbar and gets their own budgeted key (see token exchange). Pointing equivalent machinery outbound is real work, but it is not from scratch.

So the honest framing: the expensive part is the credential lifecycle, and nobody is blocking it.

One thing we will not do

Where subscription-backed access works today for third-party tools, it generally works by presenting a vendor's own first-party client identity and calling a product backend rather than the public API. We are not going to ship that. If the only way to obtain a credential for a given provider is to impersonate that provider's own client, then that provider is unsupported and we will say so, rather than putting operators on the wrong side of an agreement they did not read.

If a provider offers a genuine third-party path for subscription-backed access, we would support it.

What we would like input on

• Is the absent-user case the real requirement for you, or is passthrough enough? This is the question that decides whether this is worth building.
• Where should credentials live? Busbar's governance store, or delegated to a kind: secret plugin so operators choose (Vault, cloud secret managers).
• What should happen when a refresh fails mid-flight? Fail that caller's requests only, fall back to the deployment's own key, or refuse to start.
• Does anyone need this for a provider that already offers per-user API keys, rather than OAuth? That is a strictly easier version of the same feature and might be worth doing first.
• What are we missing?

No timeline on this yet. Comments and use cases welcome, especially concrete ones, since the absent-user question above is the deciding factor.

[frankyw]

Thank you for opening the discussion @MattJackson

Here is my use case. I am building a variety of applications that I have been routing through LiteLLM, for all the reasons LiteLLM, Busbar and others exist. I'd like to move to Busbar and also use the OpenAI subscription I have.

Up until now my apps have been using LiteLLM endpoints, and some of my apps have been using Hermes REST API to access OpenAI models via Codex auth (path 3). Hermes is good for its agentic capabilities (path 2), but sometimes those are not needed and direct model calls from the app make more sense. While I can pass these via Hermes (path 3), it would make more sense to pass them via a router like Busbar.

Current state:

1. App -> LiteLLM -> LLM
2. App -> Hermes Profile (full agent, skills, tools, etc) -> LiteLLM or OpenAI
3. App -> Hermes Profile (no skills or tool) -> OpenAI LLM
4. App -> Busbar -> Opencode Go, Ollama Cloud (newly added)

LiteLLM: Opencode Go, Synthetic, Ollama Cloud

Desired state:

1. App -> Busbar-> LLM including OpenAI
2. App -> Hermes Agent (full agent, skills, tools, etc) -> Busbar -> LLM including OpenAI

Busbar: Opencode Go, Synthetic, Ollama Cloud, OpenAI Codex subscription

I looked at this LiteLLM Codex OAuth Provider but its discontinued, so decided to come here and start a discussion first :)

[MattJackson]

We tested the interactive-login path. Here is what came back.

This is the evidence behind the question this issue opens with. We stopped reasoning about whether a device-code flow is possible and went and ran one, against four providers, using our own registered OAuth application in every case. No borrowed client ids, no spoofed headers.

Device code is the right shape for a self-hosted gateway: busbar shows a code, a human approves it on any device, busbar receives the token itself. No callback URL, no inbound port, no TLS certificate, no browser on the box.

MiniMax — no

The token endpoint returns unknown client_id. Closed registry, no self-serve registration, nothing documented.

Kiro — no, and this one is instructive

AWS SSO's RegisterClient is genuinely unauthenticated. We registered a client, started a real device flow with it, and it worked. Then kiro.dev's own FAQ states that use with third-party harnesses is prohibited.

Open registration is not permission. Only the terms are. Worth writing down, because the same evidence read without the second half leads to the opposite conclusion.

GitHub Copilot — the most promising of the four

GitHub's current documentation tells third parties to register their own OAuth App or GitHub App. No allowlist, no partner programme, no approval step. The copilot_requests permission note says requests count against the user's own premium allowance, which is billing-side evidence that it reaches inference rather than only account metadata.

What is missing is a documented inference base URL. That is roughly a half-day experiment away from a definite yes or no, and it is the next thing we will run.

OpenAI — the flow is real, the door is not open to us

Discovery advertises no registration endpoint, and an unregistered client id returns 401 invalid_client at the token endpoint. So the flow people are seeing in other tools is genuine, but it only opens for a client id we would not own.

Why we are not simply doing what the other tools do

We read how they do it. It is not only a borrowed client id: at least one also sends another product's user agent and a synthesised SDK fingerprint. It works.

busbar will not do that. If a busbar deployment identifies itself to a provider as something other than busbar, then every guarantee we make about what busbar does to your traffic becomes unverifiable, and that is the entire product. This is the same reason busbar's Anthropic writer already refuses to emit a header combination that would misrepresent what is upstream.

What already works today, which we had under-documented

Providers that hand you a token you can hold work right now: z.ai's GLM Coding Plan, Moonshot/Kimi, Qwen, MiniMax, Ollama Cloud, Mistral. busbar already ships catalog entries for those endpoints, the token goes in api_key, and nothing else is needed.

That is a documentation gap on our side rather than a feature gap, and it is being fixed. It is not the per-user model this issue is about, but it covers more subscription-style plans than we had realised, and it is the answer for a single developer today.

Where that leaves the question this issue asks

The passthrough model described above stays the right layering for the multi-user case: the application owns the user's session, so it should own the user's credential. Nothing here changes that.

What device code would add is the single-operator case, where there is no application holding a session and the person running busbar wants their own seat to pay. Of the four we tested, Copilot is the only one where that currently looks achievable without misrepresenting ourselves, and it is unproven until the base-URL experiment runs.

We will update here either way rather than let it go quiet.

[MattJackson]

Triage note, leaving this open deliberately.

This is the only one of the four open issues that is not 1.5.3 release breakage. #50, #51 and #52 were all the same release incident and are now closed with evidence. This one is a design question with an open request for input, and it should stay open until that input arrives or the question is answered — closing it would discard the RFC, not resolve it.

Status relative to 1.6.0

Nothing here is scheduled for 1.6.0. 1.6.0 is a structural release — the protocol/plane split, the busbar-api crate boundary, the protocol-plugin ABI — and it adds no per-caller credential storage, no outbound OAuth client, and no change to how a provider credential is resolved. The single-credential-per-provider model this issue describes as the status quo is still the model on dev.

That is not a rejection. It reflects the framing in the issue itself: the expensive part is the credential lifecycle, and the deciding question — is the absent-user case the real requirement, or is upstream_credentials: passthrough enough? — has not been answered by anyone yet. Building the lifecycle before that answer arrives would be guessing at the requirement.

What 1.6.0 does change, and it is not nothing

The plugin ABI work makes the "where should credentials live" question materially cheaper to answer later. The issue asks whether credentials belong in Busbar's governance store or behind a kind: secret plugin so operators choose their own backend; 1.6.0's crate-boundary work is what makes delegating that to a plugin a configuration decision rather than a fork. So the groundwork moves even though the feature does not.

Also worth recording since it is easy to lose: busbar_api::Redacted<T> — the wrapper that keeps secret material out of Debug/logs and zeroizes it on drop — is now in the busbar-api crate, and its zeroize dependency was reviewed and bumped to 1.9.0 as part of the 1.6.0 dependency batch. Whatever shape per-user credentials eventually take, that is the type they will be held in.

What would move this

The issue asks four specific questions. The first is the gate: does anyone need the absent-user case (background jobs and scheduled agents acting on a person's behalf), or is passthrough — where the calling app holds and refreshes the user's token — sufficient? Passthrough is shipped today and does not lose governance: Busbar still authenticates the caller with its own key, so per-user budgets, rate limits, pool restrictions and cost visibility all still work.

The cheapest useful next step is probably the one the issue already flags as strictly easier: providers that offer per-user API keys rather than OAuth. That needs the per-caller storage and selection path but none of the OAuth ceremony, and it would validate the lifecycle design against a real provider before committing to the expensive version.

Concrete use cases are what this needs, not a decision.