Smtp mail configuration with XOauth

[wernerjacobs]

Hello,

We're currently working on integrating Quarkus mail with our application and need to authenticate to smtp.office365.com using OAuth. Unfortunately, the documentation doesn't provide specific guidance on configuring Office 365 mail. We've attempted to replicate configurations used for other mail servers, but so far, we haven't had much success. Currently, we're encountering an SSL handshake issue and are unable to proceed.

Our firewall settings should allow communication with smtp.office365.com on port 587, so we don't believe that's the source of the problem. However, when attempting to send a message, we're seeing the following error in our logs:

Caused by: io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record: [error message]
at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1314)

Has anyone encountered similar challenges with configuring mail for Office 365 mail servers? We've verified that the protocols and cipher suites are correctly configured, so we're unsure what else could be causing this error.
Does anybody know which configuration properties should be set?

We are setting following properties

quarkus.mailer.auth-methods=DIGEST-MD5 CRAM-SHA256 CRAM-SHA1 CRAM-MD5 PLAIN LOGIN
quarkus.mailer.start-tls=REQUIRED
quarkus.mailer.from=XXXX
quarkus.mailer.host=smtp.office365.com
quarkus.mailer.port=587
quarkus.mailer.username=XXX
quarkus.mailer.password=XXXX
quarkus.mailer.ssl=true
quarkus.mailer.login=XOAUTH2
quarkus.mailer.trust-all=true

Any insights or assistance would be greatly appreciated.

Thank you

[quarkus-bot[bot]]

/cc @cescoffier (mailer)

[cescoffier]

The error you get means that it tries to connect to the server, but it is not encoded using TLS. So, something is wrong in the configuration of the mailer. Maybe try without the ssl=true.

[wernerjacobs]

Thank you for the advice. We're encountering an unauthenticated error while attempting to connect to the SMTP server. Our requirement is to establish the connection using STARTTLS and XOAUTH2 authentication methods.
We have been provided an appid, secret and tenantid.

However, I'm uncertain where to input the client ID, secret ID, and tenant ID. I've come across a configuration (Spring boot ) on Stack Overflow that addresses this setup specifically for Outlook 365:

spring.mail.host=smtp.office365.com
spring.mail.protocol=smtp
spring.mail.port=587
spring.mail.username=messagerie@domain.com
spring.mail.properties.mail.smtp.ssl.enable=false
spring.mail.properties.mail.smtp.auth=true
spring.mail.properties.mail.smtp.sasl.enable=true
spring.mail.properties.mail.smtp.sasl.mechanisms=XOAUTH2
spring.mail.properties.mail.smtp.auth.xoauth2.authority=https://login.microsoftonline.com/e***a/
spring.mail.properties.mail.smtp.auth.xoauth2.client.id=bc
spring.mail.properties.mail.smtp.auth.xoauth2.client.secret=4A**
spring.mail.properties.mail.smtp.auth.xoauth2.scope=https://graph.microsoft.com/.default**
spring.mail.properties.mail.smtp.starttls.enable=true
spring.mail.properties.test-connection=false
spring.mail.properties.mail.debug=true
However, I'm unable to find equivalent values for xoauth2.authority, client.id, and client.secret in the Quarkus guide (marked in bold). Integrating XOAuth2 involves OAuth, but I'm uncertain about linking a Quarkus OIDC client to the SMTP component.

I would appreciate your insights on this matter.

[cescoffier]

We do not support xoauth2 just yet for the mailer. It's technically possible, but the mailer comes from Vert.x, which has its own OAuth support (different from the Quarkus one). I need to see how we can use it directly (with the risk of duplicating oauth support) or if we can use the Quarkus one (I doubt without some refactoring).

For reference, this is how it's implemented in Vert.x: vert-x3/vertx-mail-client#94.

\CC @sberyozkin

[sberyozkin]

@wernerjacobs @cescoffier, my understanding is that it is very specific to the Mail client, and I believe it requires a Vert.x web Client call, sending the client id, secret and other required parameters as form parameters, which will give JSON with an access_token property and then the mail client sets this token in the mail request. I can prototype some code if you show me where in the Quarkus mail client this token must be set.

Adding a quarkus-oidc-client dependency would solve that easily but indeed, I'm not sure it is necessary.
But if it is already supported natively at the Vert.x mail client level then please use that option - it will not conflict in anyway with what Quarkus does around OIDC/OAuth2

[sberyozkin]

@cescoffier OK, if the code flow is involved, then here is an option which I believe will (may) work:

• quarkus-mail-client adds a quarkus-security dependency only - it will give an option to support the injection/Arc retrieval of TokenCredential
• the application which requires an authorization code flow support adds a quarkus-oidc dependency and does quarkus.oidc.auth-server-url=https://login.microsoftonline.com/e***a/ quarkus.oidc.client.id=bc quarkus.oidc.credentials.secret=4A** quarkus.oidc.authentication.scopes=https://graph.microsoft.com/.default** quarkus.oidc.application-type=web-app
• With quarkus OIDC, the current request URL is a callback URL for the authorization code flow, ex, if the application only has @Path("/mail") getMailResponse(){} then localhost:8080/mail is what has to be registered as a callback in outlook365.com, or it can be customized with quarkus.oidc.authentication.redirect-path=/my-callback
• User accesses the Quarkus frontend, is redirected to outlook365.com, authenticates, lands on the Quarkus endpoint which uses Mail client and this mail client is called
• Mail client checks the injected Instance<TokenCredential> - if it is set it represents an authorization code flow access token, and it uses it as needed

So the proposal here is to modify the mail client to take care of Instance<TokenCredential> only. The actual producer of it can come from quarkus-oidc or from quarkus-smallrye-jwt and it will handle authorization code flow, as well as bearer access token cases

[sberyozkin]

This is how the OIDC token propagation works with the authorization code flow - users just attach @AccessToken to whatever REST Client they use and the access token is propagated as HTTP Authorization, Quarkiverse Google Cloud project does it too (so all of its clients, PubSub, Bigquery, etc can use it) - it all revolves around Instance<TokenCredential>.
Having extension specific OIDC/OAuth2 integrations can work but does not scale very well.

[andreas-eberle]

Is there already an issue for this or should we create one? I'm also running into this issue as a customer has office365 and they now need to disable a security policy just to make sure our service can continue to use another authentication than XOAUTH2. It seems Microsoft disables the other authentication methods by default.

[cescoffier]

Please open an issue. Unfortunately I did not have time to look at it.

[andreas-eberle]

I created the ticket: #39359
Thanks for your support!