I'm having the same issue as OP.

By default the Resource Details Endpoint URL is set to https://outlook.office.com/api/v1.0/me, this gives the error:

When this is changed to v2.0 (https://outlook.office.com/api/v2.0/me), the error changes to:

I also tried settings this to https://graph.microsoft.com/v1.0/me (since all Outlook APIs are deprecated/replaced by Graph https://docs.microsoft.com/en-us/previous-versions/office/office-365-api/api/version-2.0/use-outlook-rest-api) but no luck:

I guess the reason for that error is missing scope in the authorization request (it should include https://graph.microsoft.com/.default), but it seems like those are hard coded to:

Changing the scopes in the OAuth2 settings has no impact.

Edit: Also I am signing in with the correct account.

    I'm the same jerer, I've had these errors and some others. The sign in logs on the Azure account indicate that sign in was successful.

    Same here. Can't find the combination to make this work.

    jerer

    Strange as we hardcore v2 api urls. I wonder why it’s giving you v1 🤔

    Cheers.

      KevinTheJedi
      The authorization/token endpoint URLs are correctly v2 by default, just the API URL (Resource Details Endpoint) is by default 1.0. Although setting it to 2.0 doesn't help either.

      I think the plugin should be updated to use Graph API/scope since Outlook V2.0 REST endpoint is also deprecated and will be decommissioned in November 2022. Source: https://docs.microsoft.com/en-us/previous-versions/office/office-365-api/api/version-2.0/use-outlook-rest-api

      So the URLs in scope should be https://graph.microsoft.com/IMAP.AccessAsUser.All https://graph.microsoft.com/POP.AccessAsUser.All https://graph.microsoft.com/SMTP.Send, and Resource Details Endpoint/User Details URL should be https://graph.microsoft.com/v1.0/me.

      edgarnadal

      Basically the URLs it gives you when you go to Enterprise Applications and click Endpoints at the top.

      Cheers.

      When I pulled apart the .phar file, it has v1.0 manually set in the configuration. I saw the same thing but I just changed it to v2.0. When I tested I used an in-private window and logged in with my login to the osTicket but used the O365 account for the e-mail address, it still gives the error message so I think there's something wrong with the checks, plus it doesn't even say what the wrong e-mail address is in the error. Like others, it shows successful on the Azure side.

        rblake

        We have changes coming soon that should reflect the appropriate URLs and scopes. Stay tuned!

        Cheers.

          Our office is also using osTicket for our customer service and IT departments and Microsoft O365 for our email. We're very interested in getting this to work as well. Please let me know if there's anything I can do to help move this plugin along.

          We're interested as well as a new OSTIcket setup. I just stumbled upon IMAP etc going away October 1 and we need to have this setup for us to use OSTicket before that date.