The Orchestrator API currently only supports user Backstage tokens for authentication. It does not support:

• Static tokens — A pre-configured bearer token (e.g., from app-config.yaml) that can be used to authenticate API requests without a user session.
• Plugin-to-plugin (service-to-service) authentication — Tokens obtained via 

const { token } = await auth.getPluginRequestToken({
  onBehalfOf: await auth.getOwnServiceCredentials(),
  targetPluginId: 'orchestrator',
});

which is the standard Backstage mechanism for backend plugins to communicate with each other.

Problem:

Backend plugins that need to call the Orchestrator API from non-user contexts (e.g., scheduled tasks, background jobs) cannot authenticate because there is no user request to derive a token from.The only workaround is to obtain a user on-behalf-of token from an HTTP request handler and thread it through the entire call chain. This means:

• Scheduled tasks that need to check workflow instance status or trigger workflows cannot authenticate at all.

• Backend plugins calling the orchestrator must always thread a user token from the HTTP layer, adding complexity and coupling.

Expected Behavior:

The Orchestrator API should support:

• Static tokens — A bearer token configured in app-config.yaml, enabling external systems or scripts to call the API.
• Service-to-service tokens — Tokens minted via Backstage's auth service using getOwnServiceCredentials(), enabling backend plugins and scheduled tasks to call the Orchestrator API without a user context.