Dynamic authorization tokens

[ari-becker]

🚀 Feature Proposal

Currently, TURBO_TOKEN is defined as an environment variable, therefore making changes to the token(s) requires a full restart. Instead, authorized tokens should be stored in a database, and a UI or API should be exposed to add or remove tokens from that database; ideally allowing users some kind of SSO login flow which ends in issuing them a token.

Motivation

We're looking at alternatives to Vercel hosting the Turbo remote cache, because Vercel charges $20/user/month. If we do pay Vercel $20/user/month, then each user gets their own API token, and removing a user from Vercel also invalidates their access to the cache. We'd like to self-host the cache, but manually maintaining a list of tokens is an operational headache we'd like to avoid. If we were to decide to restrict ourselves to use only one API token (and share that API token via 1Password etc.), then we might as well make a shared Vercel user on Vercel's free tier for that purpose.

[fox1t]

I like this proposal. I wouldn't say I like adding a DB. It could be an optional DB, though. I also like the idea of having a UI.

[lukeshay]

Maybe TURBO_TOKEN token could be updated to handle a comma-separated list of tokens. E.g. TURBO_TOKEN=token1,token2,token3. That way no DB is required and you can add/remove multiple tokens.

[ari-becker]

I ended up switching companies, but the way we planned around this limitation was, instead of running a turborepo-remote-cache from a central location (thus prompting the whole question of a shared token vs. multiple tokens), instead we planned to run turborepo-remote-cache locally, a separate copy on each dev laptop + instantiate at runtime in CI, with a shared storage provider (e.g. S3). Thus each developer would be responsible for providing personal credentials, and CI would use CI's credentials, to connect to the same S3 bucket, for example.

[slongdotexe]

I thought I would add to this issue as having more control over verification of a user's Authorization token is somehing I'm very interested in. I can also see that some down-stream projects like cdk-turborepo-remote-cache have identified this as an area for potential improvement.

One approach for this that I think would allow developers or package maintainers this flexibility, is to let a consumer pass in a custom handler function for verifying the Auth token. From what I can tell, this could be achieved like so:

• Abstract the existing token verificaiton code to a defaultAuthoizationHandler function.
• Update createApp to accept a remoteCacheOptions object, with an authorizationHandler key, with the above. function as a default.
• Pass remoteCacheOptions to turboRemoteCache.
• Update documentation with examples of how to implement this, possibly under an 'Advanced Usage' section, with code snippets etc.

I'm interested in implementing this feature but it would be nice to have some feedback on the suggested approach or any other considerations first (: