Improving the dialog to get the authentication token

[marco-brandizi]

I've an O365 email account that is managed through the damn InTunes, so I use a chain like Thunderbird - DavMail - O365 (which might require to tweak the client ID, as explained here).

When I log in from TB, DavMail shows me a dialogue where it tells me to open the URL in which I can go through the corporate login dialogue, I click on 'Open', the web browser shows the usual authentication challenge, I type user/password, then I have another dialogue where I type the authenticator OTP code, and eventually the browser shows a blank page.

But that's not a problem, because I can open the Javascript console and see the log message mentioning the URN that contains the authentication token (see below). I copy-paste such URN back to the DavMail dialogue and click 'Send'. At this point, everything goes on as usual, DavMail talks to O365 and TB gets the last messages.

My question is: can this be made simpler? For instance, is there a way to tell the browser to go back to the DavMail dialogue with the urn:... string? Is it possible to implement the dialogue above inside DavMail (eg, using a Java web browser engine)?

[mguessan]

That's exactly what O365Interactive does: proceed with authentication inside an embedded web browser and capture OIDC code to obtain a token.

Unfortunately Java web browser support is limited (relies on OpenJFX) and not compatible with advanced Microsoft authentication mechanisms like Windows Hello for Business.

The only alternative I can see is to have a dedicated Edge based embedded browser (Webview2) with full native authentication support.

[marco-brandizi]

Hi @mguessan,

I'm not sure I get it: I'm already using the O365Interactive protocol, it doesn't seem to be using any browser.

One thing I see all the time in Chrome and other browsers is that URLs to authenticate in services like Zoom calls or Slack channels (eg, reported in emails) first open the default browser to offer the authentication dialogue, and then, after successful login, the browser knows how to open the target desktop application.

There must be some common protocol to manage that, since I see the same behaviour and graphics for different applications and different browsers. Hence, maybe a possible solution for DavMail is intercepting those urn:* answers that O365 gives to the browser and re-route them back to DavMail.

This might be relevant. This way, urn:ietf:wg:auth:oob:* could be associated to DavMail, which, I realise, may grab too much (ie, other applications might be using the same answer URLs), but probably the OS is able to propose the user multiple choices when it sees multiple apps associated to a given URL pattern.

[dionorgua]

Hi, I'm in exactly same boat. Company is now enforcing InTune, so I need to change clientID and final URL to urn:ietf:wg:auth:oob:.

Right now I'm using davmail 6.1 (downloaded as .zip) on Debian with it's default JRE:

• O365Interactive (where davmail shows own browser window) is able to authenticate, but final step (with redirect to urn) doesn't work:

2023-07-13 16:23:42,633 WARN  [AWT-EventQueue-0] davmail.exchange.auth.O365InteractiveAuthenticatorFrame  - Unable to register protocol handler
2023-07-13 16:23:46,091 INFO  [JavaFX Application Thread] davmail.exchange.auth.O365InteractiveJSLogger  - Web Authentication API is not supported on this browser.
2023-07-13 16:23:56,672 ERROR [JavaFX Application Thread] davmail.exchange.auth.O365InteractiveAuthenticatorFrame  - java.lang.Throwable: Malformed URL Malformed URL
2023-07-13 16:23:57,619 ERROR [CaldavConnection-49588] davmail.exchange.auth.O365InteractiveAuthenticator  - Authentication failed Malformed URL
2023-07-13 16:23:57,620 ERROR [CaldavConnection-49588] davmail  - Authentication failed Malformed URL
davmail.exception.DavMailException: Authentication failed Malformed URL
        at davmail.exchange.auth.O365InteractiveAuthenticator.authenticate(O365InteractiveAuthenticator.java:181)
        at davmail.exchange.ExchangeSessionFactory.getInstance(ExchangeSessionFactory.java:182)
        at davmail.exchange.ExchangeSessionFactory.getInstance(ExchangeSessionFactory.java:97)
        at davmail.caldav.CaldavConnection.run(CaldavConnection.java:178

• O365Manual works but requires same steps with Firebug to copy destination URL

I've found solution that works well enough: run davmail azul once. It'll download some more libraries and a bit different browser window will be used. Now I can authenticate without any copy/paste steps.

[dngray]

Company is now enforcing InTune

How do you know if they are doing that?

O365Manual works but requires same steps with Firebug to copy destination URL

Can you give more details about the steps with Firebug? can this be done with the browser web dev tools? (Ctrl+Shift+I)?

I wanted to use it with the headless docker container kran0/davmail-docker. I made sure to build the container myself against the latest version. The docker container uses davmail.servers=server and had to be used with davmail.mode=O365Manual. The reason for this is because those libraries installed with azul aren't there. They weren't in the copr repo mguessan/davmail either.

In manual mode you're presented with this on the terminal:

Please open the following link: https://login.microsoftonline.com/common/oauth2/authorize?client_id=d3590ed6-52b3-4102-aeff-aad2292ab01c&response_type=code&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_mode=query&login_hint=user%40example.com&resource=https%3A%2F%2Foutlook.office365.com proceed through authentication steps and paste back the final url that contains authentication code (blank page)

What I found is the login page would get stuck and perpetually leave me waiting with the spinny dots at the top.

It appears though authentication did happen because if I visit outlook.office365.com it logs me straight into the webmail. I don't get redirected to this "blank page" however.

run davmail azul once. It'll download some more libraries and a bit different browser window will be used. Now I can authenticate without any copy/paste steps.

When the mode was set to davmail.mode=O365Interactive and davmail.servers=workstation the interactive window did appear. When logging into that everything worked and the token was extracted.

I'd like to know what I am missing from the O365Manual configuration? Why doesn't it direct me through to this "blank page"?

I did make some wire debug logs but it didn't really reveal what the issue was. I did need those two options as it seems that they won't allow either Thunderbird or Davmail's client_id. The owl extension did work, but I don't plan on using Thunderbird beyond testing.

[dngray]

Java web browser support is limited (relies on OpenJFX)

@mguessan By the way I got a warning about that.

WARNING: A command line option has enabled the GTK 2 library WARNING: The JavaFX GTK 2 library is deprecated and will be removed in a future release

Does this mean that the Interactive mode will simply not work on Linux anymore? This was usin gthe embedded JRE "openjdk version "15.0.10" 2023-01-17.

alternative I can see is to have a dedicated Edge based embedded browser (Webview2) with full native authentication support.

The aerc wiki mentions:

Alternatively, carbonyl runs chromium in a terminal, complete with the necessary javascript capabilities to access the authorization page on a headless machine.

Maybe this is an option? Although it doesn't seem very maintained. Maybe a more robust approach is something that uses webview. I saw this approach with a particular Neovim plugin I use that uses a webview for the markdown preview.

Seems there are bindings for java: https://github.com/webview/webview_java

The good thing about that is seems more modern platforms are supported.