Storing OAuth token in secrets manager?

I’m opening this issue to inquire whether you would be open to merging a PR that implements an option to store the OAuth token in a Secrets Manager (e.g. AWS Secrets Manager, Github Secrets or Terraform Cloud Workspace Variables) instead of the local config. This would facilitate managing OAuth authorization and token creation from a local computer, while making the token seamlessly available to a remote server running email-oauth2-proxy. It would also facilitate persisting the token if the remote server needs to be destroyed and recreated.

As mentioned in a prior issue, I’ve been working on an infrastructure-as-code project which uses Terraform to automatically configure an AWS server running email-oauth2-proxy. I’ve just made a first version of my work public at: michaelstepner/email-oauth2-proxy-aws.

As you might anticipate, the biggest limitation of my automated server configuration is authenticating with the email provider to obtain OAuth tokens. Thanks to your prior work, after creating the lightweight server I’m able to authenticate manually via SSH using --no-gui and --local-server-auth. But I would love to configure a more elegant solution someday.

I wouldn’t ask you to implement this yourself, of course, unless you were interested in doing so.

Implementation

I considered a command-line argument, but I’m currently envisioning a per-account configuration option like token_store below:

[[e-mail]]
permission_url = https://login.microsoftonline.com/common/oauth2/v2.0/authorize
token_url = https://login.microsoftonline.com/common/oauth2/v2.0/token
oauth2_scope = https://outlook.office365.com/IMAP.AccessAsUser.All https://outlook.office365.com/SMTP.Send offline_access
redirect_uri = http://localhost
client_id = *** your client id here ***
client_secret = *** your client secret here ***
token_store = aws_secrets_manager

If that configuration option were left unspecified, it would default to local and the behaviour would follow the status quo, storing the token in the config file. This would preserve backward compatibility, and maintain simplicity for the majority of users who are using this software as a local client in their system tray.

Additional configuration required for the secrets manager could either be via environment variables (e.g. credentials for access to the secrets manager) or the configuration file.

[simonrob]

Excellent! Thanks for the work on this - great to see you found an approach with minimal impact to the proxy’s core features. Let me know how you get on; happy to review fully after that with a view to merging.

[michaelstepner]

FYI @simonrob, I have a work-in-progress fork that implements an MVP of this feature, storing tokens in AWS Secrets Manager.

Before opening a PR to propose merging this feature upstream, I plan to:

• Test it for a while on my server to ensure it’s working as expected
• Add code to seamlessly create the secret if it does not yet exist.
  • Right now it assumes the secret exists and simply reads/writes to it…which is fine in my case because I use Terraform to handle the creation of an empty secret.

There’s no need for you to review my work-in-progress, but I wanted to give you and anyone else looking at this issue a heads up! (especially since I see it’s referenced every month or two from other issues)

---

My key concern before merging would be about overcomplicating the proxy – I’m quite keen to keep it as simple and focused as reasonably possible, so if it’s a straightforward change to add this capability then I’d be open to it, but if it would end up drawing in lots more dependencies and adding lots of extra complexity then I’d be less keen.

I’m hoping this implementation is simple enough that it would meet your objectives!

1. It adds an optional argument --aws-secrets:

• --aws-secrets enables the proxy to store OAuth 2.0 tokens remotely in AWS Secrets Manager, rather than storing them in the local configuration file. This will only be applied to accounts which have an aws_secret parameter configured in the local configuration file, containing the ARN or name of the secret. To use this feature, you must install the requirements in requirements-aws-secrets.txt and set up authentication credentials for your AWS account.

1. It adds an optional account-level configuration parameter, aws_secret:

[[e-mail]]
permission_url = https://login.microsoftonline.com/common/oauth2/v2.0/authorize
token_url = https://login.microsoftonline.com/common/oauth2/v2.0/token
oauth2_scope = https://outlook.office365.com/IMAP.AccessAsUser.All https://outlook.office365.com/SMTP.Send offline_access
redirect_uri = http://localhost
client_id = *** your client id here ***
client_secret = *** your client secret here ***
aws_secret = *** ARN or name of secret in AWS Secrets Manager ***

1. It adds new code to AppConfig._load() and AppConfig.save() to handle the option of loading/saving OAuth tokens from the remote AWS Secrets Manager. Around 40 lines of code total.

2. The only new dependency is boto3, and it is only loaded if the --aws-secrets argument is specified.