Ability to generate API Tokens for non backstage backend programmatic access

Feature Suggestion

There has been some great work to ensure API requests are authenticating for backend-to-backend plugin communication and in general we can ensure all requests to the backend are authenticated via a middleware. However if you are programmatically accessing the catalog API from another service or programmatically via a script there is no way currently to generate an API token for authenticated access to the API.

The feature suggestion is to give guidance or a way to generate API tokens for external access to the backstage API.

Possible Implementation

A potential solution would be to have a command in the backstage-cli that can generate the token, it would need access to the BACKEND_SECRET set in production or whatever environment you are generating the secret for since each environment should have a separate secret.

BACKEND_SECRET=XXX yarn backstage-cli create api-token --name XXX

The implementation would under the hood just need to call const { token } = await this.tokenManager.getToken(); or the equivalent logic in getToken

Another potential solution would be an admin panel somewhere in backstage where you could generate and view all api tokens so you could easily revoke access of certain tokens.

Context

We are trying to improve the overall security of Backstage by implementing and enforcing authentication for the entire API. However we have services and scripts which programmatically access the catalog API and we cannot enforce authentication until there is a way for programmatic access to utilize an API token as well.

[Rugvip]

I think admin panel or that kind of thing is probably a sane long-term goal, perhaps with support for Client Credentials flow, certificates, or some other form of long lived token management. It’s not something we have the bandwidth to take on right now though, so we’d need someone else to drive that work to move it forward. Happy to assist with that though.

The current service-to-service auth method is a bit of a stop-gap to allow us to implement permissions in a meaningful way, but it’s not yet intended as a method to completely block access to the backend routes. That’s still customization that has to be built on top using custom middleware.

What I suggest for now is that we create a lightweight backend client package of some sort. A package that you would use if you want to talk to Backstage from an external service. It would be Node.js to avoid needing to support all different languages and frameworks out there, but it can serve as a reference implementation for how to implement the needed functionality. The package most likely only has a single external API initially, something that lets you generate backend tokens using a static secret, just like the ServerTokenManager.

[knksmith57]

Subscribed and bigggg +1

We’ve very recently implemented quite a few workarounds for exactly this. First to lock down backend access to authenticated users/sessions, then to facilitate issuing long-lived tokens for programmatic catalog API access from external systems.

It’s all pretty sketch and we would love to better understand the intricacies (and roadmap/plan) for all things authentication, identity, and permissions.

There’s been so much great movement on those systems lately (👀 @Rugvip) that it’s sometimes really tricky to keep up with what’s happening and how we should be investing in our own bespoke solutions while still preparing for the future of authN+Z within Backstage core.