To be fair, there are a few other things you can do with a username/password that you can’t with an access token. Like potentially access code and other projects on the webIDE, change the password making all auto-access-token-generating scripts require updating anyway, etc.
If the solution to a long-term deployment is “use the username and password” why have access tokens at all? It makes access tokens sound like a solution waiting for a problem to me. Since I can “expire” my username/password any time by changing the password, that “benefit” is null… unless someone got my username/pass from a text file/script and changed it for me (through something like the ShellShock exploit maybe?)
This is quite a big deal for non-tinkerers. What is Spark’s (@zach) official solution to someone who want to put core’s in their products/projects that have no humans to enter credentials on a regular basis and don’t want to have a separate username/password for every installation? (since you wouldn’t necessarily want people who have access to one project/installation to have access to all others.)
An ideal access token system would let the user decide how long they want their token to live. Much the way many forms of secure certs work. You can pick the expire date either by specifying it during creation or purchasing many years in advance. Its not something that is fixed at only a single period of time because the creators and users/backers of the system know everyone’s situation isn’t the same.
Accept the limits of a local cloud (not being completely feature parity with spark cloud) and change the code there dealing with tokens to suit the needs of the project. From the sound of it though, the features you need are all in the local cloud code already.
Create new username/passes for each project and transfer (unclaim/claim) the relevant cores. Then implement the token lookup suggestions in a monthly cron. That way there is some protection between accounts/projects in case of a breach on your system that creates new tokens.