This stems back to #104, which was ultimately an explanation for how the interactive delegated flow was indeed secure.

So I understand the inherent security with using "any" email client password when using a delegated flow, since that requires immediate user interaction to complete the auth process, and therefore the resulting tokens are encrypted with the original email client password sent, so subsequent requests would need to use the same password to avoid a user interactive re-authentication. So that inherently keeps the delegated flow secure, HOWEVER if using client credential grant flow, that is simply not the case. With CCG, if I send a different password, sure the error retrying login due to exception while decrypting OAuth 2.0 credentials will be thrown, but the program will attempt to re-authenticate and generate new access tokens automatically, and since CCG doesn't require any user interaction at all and relies on the client/app id, tenant id, and client secret already stored in config, the new tokens are generated and stored w/o complaint.

This effectively allows a CCG flow to be used as an open relay for any system that can reach it with any specified password, as long as they specify the correct set of usernames.

One solution might be to allow specifying some sort of "app password" that we can add in config somehow to allow only certain email client passwords to be used. I'd imagine that adds some complexity and security risks since the same password would be used to encrypt the tokens in the same file later on, so more thought and consideration would need to be given for how to resolve that properly.

Another solution might be preventing CCG flows from automatically re-generating encryption keys based on current password when decryption fails, and maybe force manual user intervention to modify the config file in place to wipe out the bad keys (i.e. a way to get some user interaction when things go wrong).

Just some food for thought, but I do think this is a pretty serious issue that makes using the CCG flow insecure, especially if you're running other third party software on your server which could potentially exploit this (or perhaps they themselves were exploited), or god forbid you open this up on the public internet 😨...

Let me know if I'm just blatantly missing an easy way to make this secure. Since Microsoft's support for SMTP OAUTH2 w/ CCG flow was finally released earlier this year (ref this & that), setting up some sort of proxy like this would be pretty critical for finally retrofitting older SMTP clients that have no other ways of supporting this.

Thanks for the work you have put into this library! For the most part (minus some docker networking issues I'm investigating and this potential security flaw issue) it worked pretty well right out of the gate.