A lot of similar platforms have more full-featured tokens.

It would be safer to have Tokens that can auto-expire, and it would be lovely to be able to create tokens that are scoped to particular workspaces or even particular permissions within that workspace.

Current the access tokens generated by a user from the Platform can have broad permissions depending on the level of permissions of the user. For added flexibility and fine-grained control, it would be helpful to scope access tokens to limit access to certain resources/actions. For example:

A bioinformatician who is an Admin user on the Platform is setting up automation to launch workflows on the with the CLI/seqerakit. They create a PAT and use this as a secret in their GH actions or automation scripts. They want to ensure that other users cannot use this PAT to delete Pipelines, CEs, or perform other unrelated actions. Being able to scope this token to something along the lines of , , , or would be beneficial to prevent this.

A client would like to use a service account for generating an API access key. However with SSO enabled logging in with the service account is problematic -- i.e. can't bypass the login process to enter service account credentials.

A possibility would be to generate an API access token that is not tied to a specific individual and to easily determine when workflows are launched by an individual vs. automation processes.

- The user would be able to easily determine when workflows are launched by a person or by an automation process without adding much overhead to their daily runtime

- A workaround: create in th Tower organisation a fictional user representing the service account and configure Tower with both with SSO and email sign-in as you are suggesting in the above comment.

[links to existing issues and pieces of info]

- #179