📜 Issue Labels

• Please familiarize yourself with the issue labels used in this project: LABELS.md

🔎 Search Terms

"auth-backend", "long-lasting sessions", "offline access"

🗃️ Project Area

Auth

🔖 Need

There are a couple new types of clients that we want to add support for in Backstage. Both CLI clients that want to authenticate end users towards local Backstage deployments, as well as MCP clients that want to do the same. A good starting point for this is adding support for device-auth through #27680, but that only takes us as far as being able to hand over a short-lived session to the client. Ideally we'd also be able to issue credentials that lasts for a longer (configurable) amount of time. That way you can go through the log-in flow once to authenticate an CLI or MCP server, and use that session for an extended period of time without needing to re-auth.

📝 Proposal

We implement a persistent session store in auth-backend that is able to issue long-lived refresh tokens for users. The sessions would need to contain the original claims that were issued for the users, and it might therefore be best to simply connect this to the existing user info store that already exists in the auth-backend.

The session store would be tied to long-lived tokens that expire after a configurable amount of time. The tokens themselves are refresh tokens and can not be used as access tokens. In order to make use of the token the client must exchange the token for the usual short-lived access token that is then used for subsequent requests.

In addition to the above, we may also want to consider extending the session store to also support storing information for auth providers. This would allow us to replace the existing pattern of re-using refresh tokens from OAuth providers and instead store them using a single Backstage session instead. This in turn can also allow for offline access delegation and fixing some refresh flows that invalidate the existing token.

🔄 Alternatives

Instead of issuing refresh tokens that are tied to a session store entry, we could instead issue regular access tokens with a longer expiration time instead. This has two problems: It's more insecure as it does not allow for any current of future method of revoking tokens without complex architectural additions. The other issue is that we'd need to store and publish the keys that tokens were signed with for a lot longer, potentially leading to excessively long lists that eventually end up hurting performance.

An option to issuing our own refresh tokens would be to re-use the ones issued by upstream providers instead. For example we might use a Google refresh token and store that in the CLI instead. This does avoid the need to build our own session store, and we forward session revocation to the upstream provider instead which is often desired. It does expose that refresh token a bit more, but using our own token really be better in that regard. The biggest hurdle is that not all auth providers provide a refresh token that we can use. Any proxy provider will have the persistent session in a session cookie that is not accessible to the auth-backend, and so there's no long-lived secret that we could use. With proxy providers being by far best in terms of UX for sign-in, I think we should find a solution that works for them too.

Have you read the Code of Conduct?

• I have read the Code of Conduct

Are you willing to submit a PR?

No, but I'm happy to collaborate on a PR with someone else