O365Interactive fails after 2FA: The request tokens do not match the user context.

[ifinkelstein]

I use O365Interactive authentication with DavMail 6.2.0 (issue persists in 6.2.1).

I have not changed my working .davmail.properties in some months.

I also have to use the following settings to login to my network:

davmail.oauth.clientId=d3590ed6-52b3-4102-aeff-aad2292ab01c
davmail.oauth.redirectUri=urn:ietf:wg:oauth:2.0:oob

After my University SSO and Duo 2FA authentication, I get a screen with Are you trying to sign in to Microsoft Office? After clicking Continue, I get a new page with the following error message:

Sorry, but we’re having trouble signing you in.

AADSTS165000: Invalid Request: The request tokens do not match the user context. Do not copy the user context values (cookies; form fields; headers) between different requests or user sessions; always maintain the ALL of the supplied values across a complete single user flow. Failure Reasons:[Token values do not match;]

Troubleshooting details
If you contact your administrator, send this info to them.
[Copy info to clipboard](https://login.microsoftonline.com/appverify#)
Request Id: e038ffbd-8a35-4fb3-9cb5-4cd22df5bc02
Correlation Id: 1d124321-b227-4c09-bc7d-c9d8498ca1c0
Timestamp: 2024-01-04T17:09:05Z
Message: AADSTS165000: Invalid Request: The request tokens do not match the user context. Do not copy the user context values (cookies; form fields; headers) between different requests or user sessions; always maintain the ALL of the supplied values across a complete single user flow. Failure Reasons:[Token values do not match;]
Flag sign-in errors for review: [Enable flagging](https://login.microsoftonline.com/common/debugmode)
If you plan on getting help for this problem, enable flagging and try to reproduce the error within 20 minutes. Flagged events make diagnostics available and are raised to admin attention.

DavMail eventually times out (nothing too interesting in the log file)

Is there a change to the Outlook clientID? Happy to help troubleshoot, if possible.

Updates:

• Is this possibly related to #248?
• I also installed and logged into my account using Outlook Desktop on the same machine. That did not resolve the issue.

[mguessan]

There were issues recently with stolen authentication token cookies/context, maybe related.

It may also be that with latest JDK DavMail is unable to register custom protocol handler, look for "Unable to register protocol handler" message in davmail.log.

You can try to change Info.plist JVMOptions to:

<key>JVMOptions</key>
<array>
<string>-Dsun.net.inetaddr.ttl=60 -Xmx512m  --add-exports java.base/sun.net.www.protocol.https=ALL-UNNAMED</string>
</array>

Did you also try the manual authentication mode ?

[ifinkelstein]

Thank you so much for getting back to me. I did notice the following WARN-level event:

Date:           Fri Jan 05 14:04:02 CST 2024 (1704485042586)
Thread:     AWT-EventQueue-0
Message #:  7
Level:      WARN
NDC:            
Category:   davmail.exchange.auth.O365InteractiveAuthenticatorFrame
Message:        Unable to register protocol handler
Location:   davmail.exchange.auth.O365InteractiveAuthenticatorFrame.<clinit>(O365InteractiveAuthenticatorFrame.java:158)
Thrown:

I added the following to the Info.plist file, but alas the protocol handler warning still crops up and I get stuck with the same failure to authenticate:

    <array>
      <string>-Dsun.net.inetaddr.ttl=60 -Xmx512m  --add-exports java.base/sun.net.www.protocol.https=ALL-UNNAMED</string>
    </array>

I also tried the following Java installations, all via sdkman, with the same WARN in the log file.

8.0.392.fx-zulu

On a related note, I noticed that DavMail 6.2.1 (latest build) doesn't generate the WARNING, but also doesn't pop up any authentication window. I can get the window (and the unable to register custom protocol handler warning) in DavMail 6.1.0 and 6.2.0

Please advise on what I can try next and thank you for your time!

[ifinkelstein]

O365Manual tests:

I can copy the URL to either Safari or Chrome and authenticate via my SSO + Duo. Then, I'm asked:

Are you trying to sign in to Microsoft Office?

The URL is: https://login.microsoftonline.com/login.srf

Clicking Continue just keeps taking me to the same page. I never see a blank page.

Should I examine the source and attempt to extract a cookie or URI? Not familiar what I should do at this stage.

[esabol]

For O365Interactive, have you tried adding --add-exports java.base/sun.net.www.protocol.https=ALL-UNNAMED to your JVMOptions in the DavMail Info.plist, @ifinkelstein ?

[ifinkelstein]

Yup, see above:

I added the following to the Info.plist file, but alas the protocol handler warning still crops up and I get stuck with the same failure to authenticate:

    <array>
      <string>-Dsun.net.inetaddr.ttl=60 -Xmx512m  --add-exports java.base/sun.net.www.protocol.https=ALL-UNNAMED</string>
    </array>

[esabol]

Yup, see above:

Oh, sorry. It was scrolled off to the right, and I didn't see it.

[ifinkelstein]

No worries @esabol . I am really grateful for your help, and for @mguessan and his amazing DavMail.

Hoping against hope that I can again be free from the suffocating O365 soon.

[esabol]

Based on other reports, it does seem as though O365Manual does not work with Duo. This is because the authentication URL that Duo uses is different, and DavMail can't parse the token it needs from what Duo responds with. Or something like that.

So your only hope (unless you want to develop a patch to DavMail to improve O365Manual to work with Duo – which I'm not sure is even possible), I suspect, is O365Interactive. The problem there is that you're on a Mac (right?) and Java on recent macOS releases doesn't come with the JFX library to open the authentication window in DavMail. You've installed some version of JFX using "sdkman", but getting the Mac version of DavMail to use it is the real challenge, I suspect.

Adding the zulu JFX library via an appropriate -classpath argument to the JVMOptions in the Info.plist might be your best bet and worth a try.

Also, if you look inside the DavMail.app bundle on the Mac, you might be able to find the davmail.jar and run that directly from the command line in Terminal with the appropriate arguments.

Just some ideas...

[esabol]

Oh, maybe try copying the zulu JFX jar file(s) to the same directory that the davmail.jar is located inside the DavMail.app bundle?

[mguessan]

Copying just the OpenJFX libs to DavMail.app will not work, you need to have full jre with fx embedded in app.

Anyway you need to go a bit further on manual mode, a.k.a authenticate in native browser. It's normal that you never get the empty page when using the urn: redirectUri, as this url is not supported by the browser.

You need to check console and / or network tab in dev tools, on last authentication step you should be able to retrieve the url with the right code.

• inside console as an error message
• in network tab as last redirect value in last http request

[esabol]

@ifinkelstein : Where did sdkman install the zulu JFX library?

Try adding -Djava.library.path=/path/to/zulu-jx --module-path /path/to/zulu-jfx --add-modules javafx.base,javafx.controls,javafx.web,javafx.fxml,javafx.swing to the JVMOptions, replacing /path/to/zulu-jfx with the correct path, of course. I think that needs to come after the --add-exports java.base/sun.net.www.protocol.https=ALL-UNNAMED.

[ifinkelstein]

Thank you for all the suggestions. Will troubleshoot some more and reply in a few days.

[ghost]

I'm having exactly the same issue. I noticed that the evolution mail client gets around it by using an OAB url, they talk about it here. This worked fine when using that mail client. So just writing it here hoping that whatever they did, you can also copy it over for davmail.

[ifinkelstein]

Had some more time to debug my config.

https://github.com/mguessan/davmail/issues/332#issuecomment-1941348657 was sufficient to authenticate with O365Manual; I'm in business again (I think)