Encryption for provider credentials #317
Description
Hey, the project looks promising and exactly what I need for me and my team.
The only thing which bothers me is the fact that while the project itself keeps one from sprinkle secrets throughout the filesystem, it on the other hand encourages to leave a secret in the form of for example a long living vault token in the configuration file on the filesystem!
If this secret leaks, all the secrets leak.
Initially I thought teller would ask for a passphrase every time it would be invoked to unlock the secret store for a short time. Similar to how the ssh agent unlocks local ssh keys protected with a passphrase.
Ideally it would work with an SSO provider (for me it's Google) just like requested here:
#303
SSO enables me to revoke access from team members leaving the project in a central way which would be nice.
If we assume that the SSO system propagates user deactivations to the providers and the access token is bound to a user thus declining access requests already, a local solution might also be feasible. Imagine you configure the access token through a teller cli call. Teller saves the access token in the users profile folder in a file but is encrypted. The user also provides a passphrase in the process.
From now on the user is asked for the passphrase each time a request to the provider needs to be sent because it needs to decrypt the local encrypted token.