Backstage plugin: per-user authentication with the OIDC on-behalf-of flow

Problem

The Spacelift Backstage plugin authenticates to Spacelift with a single API key ID and secret set in app-config.yaml. Every Backstage user reaches Spacelift through that one identity, which means:

No per-user visibility. Users see every stack and run the shared key can see, not what they are authorized for in Spacelift.
Spacelift access control doesn't apply. Spaces, RBAC and login policies are evaluated against the API key, not the person. Admins have to rebuild access rules in the Backstage permission framework or fall back to readOnly mode.
Weak audit trail. Runs triggered from Backstage are attributed to the API key, so the Spacelift audit log loses who actually acted.
Secret management overhead. An admin has to create, store, rotate and distribute a long-lived, highly privileged credential.

Requested behavior

Support an OIDC on-behalf-of (token exchange) flow in the backend plugin:

The user signs in to Backstage through the organization's identity provider.
The backend plugin exchanges that user's token for a Spacelift token issued to that user.
Every call to the Spacelift API carries the user's identity, so Spacelift applies its normal spaces, RBAC and login policies.

Expected outcome:

Users only see the stacks and runs they can access in Spacelift.
Actions such as triggering a run are allowed or denied by Spacelift and attributed to the user in the audit log.
No static API key and secret is required for interactive use (a service credential could remain optional for background jobs).

Who this is for

Organizations using Backstage as the front door to their internal developer platform, where many teams share one Backstage instance and should not all share one Spacelift identity.

Current workaround

A shared API key (ideally read-only) plus Backstage permission rules to restrict who can open the Spacelift pages. This controls access to the plugin, not access to individual stacks.

If you need this, upvote this post and add a comment describing your setup (IdP, number of Backstage users, and whether you need write actions or read-only). This board is how we size demand.