[Users] Oauth2 not working with Microsoft Exchange

David Fletcher David at megapico.co.uk
Tue Oct 11 19:44:06 UTC 2022


Paul Rolland <rol at witbe.net> wrote:

>but this I have:
>oauth2.c:339:OAuth2 - request: POST /common/oauth2/v2.0/token HTTP/1.1
><HTTP HEADER>
><MESSAGE BODY>
>
>and a HTTP response !!!
> Response: HTTP/1.1 400 Bad Request
>Cache-Control: no-store, no-cache
>Pragma: no-cache
>Content-Type: application/json; charset=utf-8
>Expires: -1
>....
>with
>
>{"error":"invalid_grant","error_description":"AADSTS70008: The provided authorization code or refresh token has expired due to inactivity. Send a new interactive authorization request for this user and resource.\r\nTrace ID: 660bb117-dffc-4b9f-b054-3764a07d0900\r\nCorrelation ID: 3e7e9a29-e3c7-42e8-bb73-7635f8f44dfe\r\nTimestamp: 2022-10-11 07:13:58Z","error_codes":[70008],"timestamp":"2022-10-11 07:13:58Z","trace_id":"660bb117-dffc-4b9f-b054-3764a07d0900","correlation_id":"3e7e9a29-e3c7-42e8-bb73-7635f8f44dfe","error_uri":"https://login.microsoftonline.com/error?code=70008"}
>
>So, I think that the TLS error is simply that the MS server is considering
>that it can drop the TLS connection following the 400 error message it sent
>to me.
>
>What is this expiration ? Do I need to go again through the whole process
>in the OAuth2 tab of the account ?
>
>Paul

Hi Paul,

It's trying to fetch /common/oauth2/v2.0/token (to get the oauth2 token
and refresh token), but saying the authorization code is out of date.
I'd guess the life of the authorisation code is quite low (minutes), so
while working out this connection issue it's expired. You'll need to
re-start the process via the Oauth2 tab in Claws.

The actual oauth2 token will have a life in hours, and the refresh token
in weeks. Every login issues a new refresh token so as long as you
regularly login you have perpetual authorisation (until you change
password or there's some other change).

But unless something has changed it could just re-start the failing
sequence of events. Could the browser "Incognito" mode you mentioned
be an issue? I don't think I've ever tried the authorisation process
with the browser in that mode. The authorisation code gets to claws via
the HTTP redirect request so I'd be surprised if "Incognito" blocks
anything - unless it strips or modifies the parameters of the redirect
URI?

Someone here found a version of Chrome in Incognito mode was dropping
redirect parameters. That was a couple of years ago but is this
happening to you? Maybe try Firefox?
https://stackoverflow.com/questions/61131821/chrome-80-handling-http-302-redirect-and-dropping-query-string

David


More information about the Users mailing list