Based on the options, which Microsoft gave us for authenticating SMTP integration application, the next step was to do the research issue for supporting generic OAuth 2.0 Authorization Code flow. Based on that we created POC. In addition to the POC, we created RFC for supporting generic OAuth 2.0 Authorization Code flow across Kibana and the proper issues for implementation: #107898, #107846, #107847, #107918, #107904. Those was closed later in favor of the other approach.
As an alternative to the implementing OAuth 2.0 Authorization Code flow, was done the research on the usage OAuth 2.0 Client Credentials flow, which is more server to server communication sufficient. The main Cons here is a stepping out of the current SMTP integration in favor of MS Exchange specific way of sending emails based on MS Graph API. Created POC
Based on the comparison of the different research results, the team made the decision to move with implementing OAuth 2.0 Client Credentials flow and using MS Graph API for sending emails for MS Exchange Server service provider.
Summary with pros and cons: https://github.com/elastic/kibana/issues/93466#issuecomment-914440697
In addition to the fixing cons about non-generic way of sending emails for MS Exchange, Microsoft has on the roadmap to add OAuth 2.0 Client Credentials support for SMTP integration.
For the selected approach opened next implementation issues:
Based on the comparison of the different research results, the team made the decision to move with implementing OAuth 2.0 Client Credentials flow and using MS Graph API for sending emails for MS Exchange Server service provider. Summary with pros and cons: https://github.com/elastic/kibana/issues/93466#issuecomment-914440697
In addition to the fixing cons about non-generic way of sending emails for MS Exchange, Microsoft has on the roadmap to add OAuth 2.0 Client Credentials support for SMTP integration.
For the selected approach opened next implementation issues: