Trying to connect oAuth2 to my O365 tenant and I'm not having any luck. After enabling the OAuth plugin, I configured a new App registration in Azure, pulled a secret key, set the Redirect URI based on the information in osTicket, set the URLs in osTicket to the values in Azure, and while I was able to get it to authenticate successfully as seen from the backend logs in Azure, I'm getting this odd message: osTicket oauth2 Email Mismatch: Expecting Authorization for [EmailAddress]. Not sure how to debug but would be happy to.

Also, just as a note, when you add an Instance under Plugins > Oauth2 Client, it only shows up there, you can't apply or link it to an e-mail account. Instead, you have to set it up from scratch from within the E-mails tab and selecting the OAuth2 - Microsoft option then selecting Config. I would expect to be able to see the created Instances as drop-down selectable options from within the Remote Mailbox setup.

    rblake

    Alright, so the error is due to authorizing the wrong email. When it redirects you to Azure you have to make sure you sign in as the account you’re attempting to authorize in osTicket. This is a hard coded requirement for now.

    As for the instances not being available/selectable in the emails, the plugin does two separate things: Authentication and Authorization. Authentication is for Agents and/or Users. Authorization is for emails. Authorization requires you to visit the provider and physically consent and accept the scopes; Authentication does not have this requirement. So when you are setting up authorization for an email we have to redirect you to the provider so you can consent and we have to know what you are authorizing and make sure it matches hence why you need to do it on the email side vs in the instance.

    Cheers.

        sjswarts

        Not at this time but it’s something that will be released shortly after stable is released.

        It’s quite intuitive on osTicket's side; from osTicket you just need the Redirect URI that’s auto generated and then from your provider you need the client id and client secret. The hard part is registering the app in Google Apps or Azure or whatever 3rd party provider you’re using. But your provider should have thorough documentation on that.

        Cheers.

          Spent quite a while trying to figure this out, from lifting generated urls from osticket to the azure app registered app to making changes to try and invoke different results.

          So far, I have two differentia results:

          updating the idp config takes me through the 365 login flow then at the end, takes me back to a white page with 404 Not Found with a URL that indicates that it would have been successful?

          https://subdomain.TLD/api/auth/oauth2?code=<long string of code here>

          idp config the URI / URL set as the following:

          Redirect uri: https://subdomain.TLD/api/auth/oauth2
          Authorization URL: https://login.microsoftonline.com/<azure-tenant-id>/oauth2/v2.0/authorize
          Access Token URL: https://login.microsoftonline.com/<azure-tenant-id>/oauth2/v2.0/token
          (the auth and access urls were changed as 365 was complaining that i would need to use the tenant ones or switch app to multi-tenant access)

          User Details URL: https://graph.microsoft.com
          Scopes: profile email

          Azure App registration platform is set as 'Web application' with the redirect uri set
          Api permissions: email profile IMAP.AccessAsUser.All User.Read User.ReadBasic.All offline_access
          (added the extra permissions as a catch all)

          Now if I change the Azure App registration platform from 'Web application' to 'Single-page application' , again with uri set as previously mentioned, then I get taken through the 365 login flow and right at the end get provided with this error:

          Sorry, but we’re having trouble signing you in.
          AADSTS9002325: Proof Key for Code Exchange is required for cross-origin authorization code redemption.

          Nothing shows on the osticket system logs, and the app reg logs show success when the app is set as a 'web application' and log the above proof key error when set as a 'single-page application'

          Hope this helps an we can find a resolution!

          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.