Enhance mailer to support XOAuth2 authentication

[sberyozkin]

This is the most earliest prototype, and it will have to be reworked. It is only for us with Clement to start playing with various setups.
Particularly, with Microsoft, the system message, if it will work, will most likely require a token acquisition request with the system username and password - it is not clear right now if we want to reuse the username and password properties for it or create new ones.

With Google, if it will work, a JWT bearer token grant will be required.
In both cases, for now, a Map of properties is expected to be filled in with the OAuth2/OIDC provider specific properties.
The token url property for this case may be set up later as that Map property or it will be discovered with another webClient call.

For TokenCredential (user login driving the token acquisition) to work, Mailer would need be refactored to accept Paulo's AuthOperation dynamically. It will also be required for the refresh token to work cleanly.

I'll play around with this code for the next few weeks with Google, Microsoft, specifically trying to see if the system email case can be sorted out.

CC @cescoffier

[github-actions]

🎊 PR Preview 2105d46 has been successfully built and deployed to https://quarkus-pr-main-42709-preview.surge.sh/version/main/guides/

• Images of blog posts older than 3 months are not available.
• Newsletters older than 3 months are not available.

[sberyozkin]

One idea which I'd like to explore after an initial POC is done, is to introduce OIDC client SPI, like a TokenProvider interface. The idea is that the code which calls tokenProvider.getToken() always gets an uptodate token, new, acquired with whatever grant necessary, or refreshed, which is what quarkus-oidc-client users get.

If that works out, eventually, then, instead of wiring in some OAuth2 specifics into the Mailer, where users would still need to configure OAuth2 related properties, they instead configure quarkus-oidc-client, and Mailer, or in fact, any other extension which needs a similar functionality, depends on quarkus-oidc-client-api with a single interface in it, and only does TokenProvider tokenProvider = getTokenProviderFromArc(); and just passes tokenProvider.getToken() to the Mailer config or rather, the current AuthOperation.

So this TokenProvider injection is about supporting token acquisitions where no user is present (without the authorization code flow), exactly what TokenCredentials can already do to represent the current authentication token.

I'm not planning to do it right now, but over time, it will be proposed as one of the options...

[sberyozkin]

@cescoffier I've got a simple demo working, where I login to Google with the request for Gmail access and get Quarkus show an access token, then, in devmode, I set the mailer password to this token, and the authentication method to XOAuth2 and it worked.

Next, I'll play around with using a JWT bearer grant supported by Google. The problem there is that one needs to create a signed authentication token using a private key which is all managed by OIDC client nicely. Right now, I'll just get that token out of band as well.

To test the code I prototyped where WebClient is used, we'll need some more info from the Microsoft users, but once we get it, it should be straightforward enough.

Then we can decide how we want to package it all.

The good news, the underlying Vert.x code is handling XOAuth2 data already prepared nicely. But it will need to become dynamic eventually, where AuthOperation can be optionally supplied with every send operation.